Как отключить XML-RPC в WordPress и не сломать Jetpack, мобильные приложения и внешние сервисы

Автор: Тимур Васильев | Опубликовано: 26.09.2026

XML-RPC в WordPress часто отключают из соображений безопасности: через этот интерфейс идут лишние запросы, а в логах нередко видно перебор методов или попытки брутфорса. Но у него есть и легитимные сценарии — старые мобильные клиенты, удалённая публикация, часть интеграций, Jetpack. Поэтому правильный вопрос не «как вырубить всё подряд», а «что именно использует XML-RPC на этом сайте и чем это заменить».

Если на проекте уже есть REST API, актуальная админка и нормальный доступ к панели, XML-RPC чаще всего можно отключить без потерь. Ниже — как проверить зависимость, как отключить точечно и как убедиться, что после этого сайт не потерял нужные интеграции.

Когда XML-RPC действительно стоит отключать

Сначала стоит понять, есть ли у вас реальная потребность в этом интерфейсе. На небольших корпоративных сайтах, блогах и лендингах XML-RPC обычно не нужен. На старых проектах с подключённым Jetpack, внешним приложением для публикации или автоматизацией через сторонний сервис — нужен не всегда, но это надо проверить, а не угадывать.

Типичные признаки, что XML-RPC можно убрать

в логах есть регулярные запросы к /xmlrpc.php без понятной бизнес-логики;
сайт не использует удалённую публикацию из внешних клиентов;
Jetpack не задействует функции, завязанные на XML-RPC;
интеграции работают через REST API, вебхуки или прямой доступ к базе не используются;
на сайте нет старых приложений, которые подключаются только через XML-RPC.

Когда отключать нельзя или нужно делать это осторожно

Если у вас подключён Jetpack, мобильное приложение WordPress, старый клиент для публикации или сервис синхронизации контента, сначала проверьте, как именно он общается с сайтом. Иногда достаточно перевести интеграцию на REST API, но иногда отключение XML-RPC сразу ломает сценарий публикации или синхронизации.

Диагностика проблемы: кто вообще обращается к xmlrpc.php

Перед изменениями полезно посмотреть, есть ли обращения к файлу xmlrpc.php и откуда они идут. На практике это можно сделать через логи веб-сервера, плагины безопасности или временную проверку ответа сервера.

Если у вас есть доступ к логам Nginx или Apache, ищите строки с /xmlrpc.php. Это самый надёжный способ понять, идёт ли туда реальный трафик или только мусорные запросы.

# Nginx access log: поиск обращений к xmlrpc.php
grep "xmlrpc.php" /var/log/nginx/access.log

# Apache access log
grep "xmlrpc.php" /var/log/apache2/access.log

Если доступа к серверу нет, можно проверить ответ напрямую. На сайте с включённым XML-RPC обычно файл отвечает не 404, а 405 или 200 с сообщением об ошибке метода. Это уже сигнал, что точка входа открыта.

curl -I https://example.com/xmlrpc.php

Важно: сам по себе ответ 200 не означает проблему, но показывает, что endpoint доступен извне. Для сайтов без нужды в XML-RPC это лишняя поверхность атаки.

Как отключить XML-RPC: три рабочих варианта

Выбор зависит от того, нужен ли вам полный запрет или более мягкое ограничение. Если задача — просто убрать доступ извне, есть несколько реалистичных подходов.

Способ	Плюсы	Минусы	Когда использовать
Плагин безопасности	Быстро, без кода	Добавляет зависимость	Если нужен простой админский способ
Код в теме или mu-plugin	Контроль и прозрачность	Нужно не ошибиться с размещением	Если есть доступ к коду и нужен точечный контроль
Блокировка на уровне сервера	Снимает нагрузку раньше WordPress	Требует доступа к конфигу	Если есть root/hosting panel и нужно жёсткое ограничение

Вариант 1. Отключение через код

Самый предсказуемый способ — вернуть false на фильтре xmlrpc_enabled. Это отключает XML-RPC на уровне WordPress, не трогая остальную логику сайта.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Лучше разместить этот код в mu-plugin или в небольшом функциональном плагине, а не в теме. Тогда настройка не исчезнет при смене темы.

Пример минимального mu-plugin:

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Вариант 2. Закрыть доступ на уровне сервера

Если цель — не просто отключить функциональность, а ещё и не отдавать лишние ответы на запросы к xmlrpc.php, можно заблокировать файл на уровне веб-сервера. Это полезно, когда сайт получает много мусорных обращений и вы хотите отсечь их до загрузки WordPress.

Для Nginx можно добавить отдельное правило:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Для Apache обычно используют правило в .htaccess или конфиге виртуального хоста:

<Files "xmlrpc.php">
    Require all denied
</Files>

Этот вариант жёстче, чем фильтр WordPress. Если у вас есть интеграция, которая всё ещё зависит от XML-RPC, она перестанет работать сразу.

Вариант 3. Использовать плагин безопасности

Если на проекте уже стоит плагин, который умеет отключать XML-RPC, можно использовать его. Это удобно для админов, но важно понимать, что плагин — это ещё одна точка отказа и ещё один слой настроек. На перегруженных сайтах лучше не плодить лишние решения, если достаточно одной строки кода.

Пошаговое решение без лишнего риска

Проверьте, используется ли XML-RPC в реальных сценариях: Jetpack, мобильные клиенты, внешняя публикация.
Посмотрите логи и убедитесь, что обращения к /xmlrpc.php не являются частью нужной интеграции.
Сначала отключите XML-RPC через xmlrpc_enabled, а не через серверный запрет.
Проверьте админку, публикацию записей, REST API и подключённые сервисы.
Если всё работает, при необходимости добавьте серверную блокировку для дополнительной защиты.

Такой порядок снижает риск случайно сломать внешний сервис. Сначала меняется поведение WordPress, потом уже усиливается защита на уровне сервера.

Как проверить, что отключение сработало

После внедрения нужно проверить не только сам endpoint, но и побочные эффекты. Если вы отключили XML-RPC кодом, запрос к /xmlrpc.php должен перестать давать доступ к методам WordPress.

Быстрая проверка через curl:

curl -i https://example.com/xmlrpc.php

Ожидаемое поведение зависит от способа блокировки:

при отключении через WordPress — endpoint может отвечать ошибкой или сообщением о недоступности;
при серверной блокировке — чаще будет 403 Forbidden;
если файл всё ещё доступен как раньше — правило не применилось или его переопределяет другой конфиг.

Дополнительно проверьте:

вход в админку и публикацию записей;
работу REST API, если сайт его использует;
Jetpack и другие подключённые сервисы;
отсутствие ошибок в логах PHP и веб-сервера после изменения.

Частые ошибки и как их исправить

Отключили XML-RPC в теме, а потом сменили тему

Это классическая ошибка. Код в functions.php темы пропадает при смене оформления. Если настройка важна для безопасности, переносите её в mu-plugin или отдельный плагин.

Сразу заблокировали xmlrpc.php на сервере и сломали интеграцию

Если у вас был Jetpack или внешний клиент публикации, серверная блокировка убьёт доступ без предупреждения. Сначала проверьте зависимости, потом ужесточайте правила.

Поставили плагин, который отключает XML-RPC, и забыли о нём

Плагин может быть полезен, но он должен быть осознанным решением. Если задача простая, код в mu-plugin обычно прозрачнее и легче поддерживается.

Проверили только главную страницу

XML-RPC — это не фронтенд-страница. Нужно проверять именно /xmlrpc.php, а также связанные сценарии: публикацию, синхронизацию, уведомления и работу сервисов, которые могли использовать этот канал.

Что делать, если XML-RPC нужен частично

Иногда полный запрет не подходит. Например, сайт использует один внешний сервис, но не хочет оставлять открытым весь интерфейс. В таком случае лучше не искать «магическую» частичную настройку в WordPress, а пересмотреть архитектуру интеграции: перевести обмен на REST API, вебхуки или отдельный защищённый endpoint.

Если вы ведёте сайт с большим количеством технических дублей, мусорных endpoint'ов и лишних функций, имеет смысл параллельно пройтись по общей чистке. В таких проектах полезны инструменты вроде Clearfy Pro, если нужен набор точечных настроек для удаления дублей и отключения ненужных возможностей, но только после проверки, что конкретная опция не ломает рабочие сценарии.

Практика безопасности и производительности

Отключение XML-RPC не заменяет базовую защиту, но уменьшает поверхность атаки. Это особенно полезно, если сайт регулярно получает брутфорс или сканирование по типовым WordPress-эндпоинтам. При этом не стоит считать, что одна эта мера закрывает все риски: парольная политика, обновления ядра, тем и плагинов, ограничение попыток входа и нормальные права на файлы остаются обязательными.

С точки зрения производительности серверная блокировка лучше, чем обработка запроса уже внутри WordPress. Если сайт получает много мусорных обращений, вы экономите PHP-ресурсы и не тратите время на загрузку ядра ради заведомо ненужного запроса.

Если вам нужно быстро понять, что именно отключено и где это сделано, держите короткий чек-лист:

есть ли зависимость от Jetpack или старых клиентов;
отключение сделано через xmlrpc_enabled или на сервере;
код лежит в mu-plugin или отдельном плагине, а не в теме;
после изменения проверен /xmlrpc.php и основные сценарии сайта;
в логах нет новых ошибок, связанных с интеграциями.

Если после отключения всё работает как раньше, а endpoint больше не доступен извне, задача решена корректно. Если же что-то сломалось, откатывайте изменение и ищите конкретную зависимость, а не оставляйте открытый XML-RPC «на всякий случай».