XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать сторонние клиенты, мобильные приложения или интеграции, которые ещё завязаны на этот протокол. Проблема в том, что у XML-RPC нет одной полезной функции: он одновременно нужен для части старых сценариев и остаётся лишней точкой входа для атак, если вы его не используете.
Ниже — разбор, как понять, нужен ли вам XML-RPC, чем его лучше отключать, как проверить, что блокировка действительно сработала, и какие ошибки чаще всего ломают сайт или оставляют дыру открытой.
Когда XML-RPC действительно стоит отключать
Если вы публикуете записи только через админку WordPress, не используете Jetpack в режиме, который требует XML-RPC, не подключаете внешние клиенты вроде старых мобильных редакторов и не принимаете контент через сторонние сервисы по этому протоколу, отключение обычно оправдано. Это не «ускорение сайта» в прямом смысле, а сокращение поверхности атаки и лишних запросов к /xmlrpc.php.
Если у вас есть интеграции, сначала проверьте их список. Типичные зависимые сценарии:
- старые приложения для публикации из телефона;
- Jetpack и похожие плагины, если они используют XML-RPC для связи;
- сервисы автопостинга и синхронизации контента;
- удалённые клиенты WordPress, которые не работают через REST API.
Быстрая диагностика проблемы
Перед изменениями проверьте, используется ли endpoint вообще. Откройте https://ваш-домен.ru/xmlrpc.php. Если XML-RPC доступен, WordPress обычно отвечает строкой о том, что сервер принимает только POST-запросы. Это не доказательство активности интеграций, но подтверждение, что endpoint открыт.
Если хотите увидеть, кто обращается к файлу, посмотрите логи веб-сервера. Для Nginx это может быть так:
grep "xmlrpc.php" /var/log/nginx/access.logНа Apache логика та же, только путь к access.log будет другим. Если запросов нет, а интеграций вы не используете, отключение обычно безопасно.
Как отключить XML-RPC: три рабочих подхода
Выбор зависит от того, где у вас есть доступ: к коду темы, к плагинам или к конфигу веб-сервера. Самый предсказуемый вариант — блокировать на уровне сервера, а не только через PHP. Но если нужен быстрый и обратимый способ, можно начать с кода.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| PHP-хук | Легко откатить, не требует правок сервера | Запрос всё равно доходит до WordPress | Когда нужен быстрый тест |
| Блокировка на сервере | Режет запрос раньше, меньше нагрузки | Нужен доступ к конфигу Nginx/Apache | Для постоянного решения |
| Плагин безопасности | Удобно для админов без доступа к серверу | Добавляет зависимость от плагина | Если уже используете security-плагин |
Вариант 1: отключить через functions.php или mu-plugin
Если нужен простой способ без установки лишних плагинов, добавьте код в functions.php дочерней темы или, лучше, в mu-plugin. Для постоянной защиты mu-plugin надёжнее: он не зависит от темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр отключает сам XML-RPC на уровне WordPress. Если кто-то попробует обратиться к /xmlrpc.php, WordPress не будет обрабатывать запрос как обычно.
Если хотите не просто отключить функциональность, а сразу возвращать ошибку на попытку доступа, можно добавить отдельную проверку:
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
}
} );Этот вариант полезен, если у вас есть нестандартные сценарии и вы хотите явно видеть отказ. Но для обычного сайта достаточно фильтра xmlrpc_enabled.
Вариант 2: закрыть xmlrpc.php на уровне Nginx
Если сайт работает на Nginx, блокировка на сервере — более жёсткий и чистый вариант. Запросы не будут доходить до PHP-FPM, а значит, вы снижаете лишнюю нагрузку.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации проверьте синтаксис и перезагрузите Nginx. Команды стандартные:
nginx -t
systemctl reload nginxЕсли у вас несколько виртуальных хостов, убедитесь, что правило добавлено в правильный server-блок. Иначе вы будете думать, что закрыли endpoint, а он останется доступен на другом сайте.
Вариант 3: блокировка в Apache
Для Apache можно закрыть файл через .htaccess или конфиг виртуального хоста. Если доступен только .htaccess, используйте такой вариант:
<Files "xmlrpc.php">
Require all denied
</Files>После правки проверьте, что модуль mod_authz_core активен, иначе директива Require не сработает. Если у вас старый стек, иногда встречаются иные правила доступа, но для актуальных версий Apache этот вариант нормальный.
Что делать, если XML-RPC нужен частично
Иногда отключать всё целиком нельзя. Например, у вас есть один внешний сервис, который публикует записи, а всё остальное должно быть закрыто. В таком случае лучше не оставлять endpoint открытым полностью, а ограничить доступ по IP или по конкретному сценарию на уровне сервера или промежуточного шлюза. WordPress сам по себе не даёт удобной и безопасной модели «разрешить только один метод XML-RPC», поэтому частичное ограничение чаще делается вне ядра.
Если интеграция уже умеет работать через REST API, лучше перевести её туда. REST API проще контролировать, его легче логировать и ограничивать по авторизации. Это обычно более современный путь, чем держать XML-RPC ради одного старого клиента.
Как проверить, что решение сработало
Проверка нужна не только после правки кода, но и после деплоя. Иначе легко получить ситуацию, когда на тестовом сайте всё закрыто, а на проде остался старый конфиг.
- Откройте
/xmlrpc.phpв браузере — доступ должен быть запрещён или не должен возвращать стандартный ответ WordPress. - Проверьте HTTP-статус через
curl:
curl -I https://ваш-домен.ru/xmlrpc.phpЕсли блокировка на сервере настроена правильно, вы увидите 403 Forbidden или другой отказ, а не обычную обработку WordPress.
- Посмотрите access.log: запросы к
xmlrpc.phpмогут остаться, но должны завершаться отказом. - Проверьте интеграции, которые вы считали зависимыми: публикация, синхронизация, мобильные клиенты.
Если после отключения что-то сломалось, не возвращайте XML-RPC целиком «до лучших времён». Сначала найдите конкретный сервис и посмотрите, можно ли перевести его на REST API или другой способ авторизации.
Частые ошибки и как их исправить
Отключили только плагином, а endpoint всё равно отвечает
Так бывает, если плагин просто прячет функциональность внутри WordPress, но файл xmlrpc.php остаётся доступным. Для реальной защиты лучше закрывать и на сервере, и на уровне WordPress.
Сломали Jetpack или удалённую публикацию
Причина обычно одна: не проверили зависимости до отключения. Решение — временно вернуть доступ, найти конкретную функцию, которая использует XML-RPC, и заменить её на REST API или другой канал связи.
Добавили правило в неправильный конфиг
На Nginx это часто происходит, когда правку вносят не в тот server-блок. На Apache — когда меняют .htaccess, а сайт обслуживается из другого каталога или правила переопределяются на уровне виртуального хоста.
Проверили только браузером
Браузер не всегда показывает реальную картину. Лучше использовать curl и смотреть код ответа. Это особенно важно, если у вас кэширующий прокси или CDN, который может маскировать поведение origin-сервера.
Практические советы по безопасности и производительности
Если ваша цель — не просто убрать лишний endpoint, а сократить поверхность атаки, не ограничивайтесь XML-RPC. Проверьте ещё и другие типовые точки входа: неиспользуемые REST-маршруты, старые пользовательские endpoints, лишние плагины и административные аккаунты с широкими правами.
- держите WordPress, тему и плагины в актуальном состоянии;
- не оставляйте активными интеграции, которые уже не используются;
- ограничьте доступ к админке по IP, если это уместно для проекта;
- используйте отдельный staging-сайт для проверки изменений;
- после правок пересобирайте кэш, если у вас есть CDN или серверный cache layer.
Если вы уже используете Clearfy Pro, там есть набор настроек для чистки сайта и отключения лишних функций WordPress. Но даже в этом случае важно понимать, что именно вы отключаете, и отдельно проверить, не завязаны ли на это внешние сервисы. Автоматическая галочка в панели не заменяет диагностику зависимостей.
В итоге рабочая схема простая: сначала выясняете, нужен ли XML-RPC вообще, затем выбираете способ блокировки по уровню контроля, после этого проверяете ответ /xmlrpc.php и тестируете реальные интеграции. Такой подход безопаснее, чем просто поставить плагин и надеяться, что ничего не сломается.