XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, публикация через сторонний клиент или интеграция с сервисом автопостинга. Проблема не в самом факте отключения, а в том, что его делают без проверки зависимостей. Ниже — рабочая схема: как понять, нужен ли вам XML-RPC, как отключить его безопасно и чем проверить результат.
Когда XML-RPC действительно стоит отключать
Если сайт управляется только через админку WordPress и у вас нет внешних приложений, которым нужен удалённый доступ, XML-RPC обычно не приносит пользы. Исторически он использовался для удалённой публикации, pingback/trackback и некоторых старых интеграций. Сейчас в большинстве случаев задачи решаются через REST API или нативные интерфейсы сервисов.
Но отключение без диагностики — плохая идея. Сначала проверьте, не использует ли XML-RPC что-то из этого:
- мобильное приложение WordPress;
- Jetpack и похожие сервисы, если они настроены на XML-RPC;
- старые клиенты для публикации;
- интеграции, которые отправляют запросы на
/xmlrpc.php; - pingback, если он вам вообще нужен.
Диагностика: используется ли XML-RPC сейчас
Самый простой способ — посмотреть логи веб-сервера и запросы к xmlrpc.php. Если там есть обращения, сначала выясните источник. Иногда это не человек и не приложение, а боты, которые перебирают пароли через XML-RPC multicall. Это уже отдельный аргумент в пользу отключения.
Проверка на уровне сервера
Если есть доступ к логам, ищите запросы к файлу xmlrpc.php. Пример для nginx:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20Если запросы идут регулярно и вы знаете, что это ваш сервис, отключать XML-RPC нельзя без замены сценария. Если запросы выглядят как массовый перебор, можно переходить к блокировке.
Быстрая проверка с сайта
Можно проверить ответ напрямую. Если XML-RPC включён, файл обычно отвечает не 404, а 200/405 с характерным содержимым. Если отключён корректно, сервер должен возвращать 403 или 404 в зависимости от способа блокировки.
curl -I https://example.com/xmlrpc.phpВажно смотреть не только код ответа, но и поведение сайта в реальных сценариях после изменений.
Как отключить XML-RPC: сравнение подходов
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | Нужно быстро закрыть доступ без правки кода | Просто включить, часто есть дополнительные меры защиты | Лишняя зависимость, не всегда понятно, что именно блокируется |
| Фильтр в теме или mu-plugin | Есть доступ к коду и нужен точечный контроль | Прозрачно, легко откатить, не зависит от темы | Нужно аккуратно разместить код |
| Блокировка на уровне nginx/apache | Нужна жёсткая защита от запросов к файлу | Запросы не доходят до WordPress | Требует доступа к конфигу сервера |
Пошаговое решение через код
Если вам нужно отключить XML-RPC именно в WordPress, а не на уровне сервера, используйте mu-plugin. Так код не потеряется при смене темы и не зависит от активной темы.
Создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам XML-RPC, но не блокирует запросы на уровне веб-сервера. Для большинства сайтов этого достаточно, если цель — убрать функциональность и снизить поверхность атаки.
Если нужно сохранить только pingback
Иногда XML-RPC нужен не весь, а только отдельные методы. Тогда можно не отключать его полностью, а фильтровать методы. Это уже более тонкая настройка, но она оправдана только если вы точно понимаете, что используете.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Такой подход убирает pingback, но оставляет остальные методы. На практике это полезно редко: если внешние клиенты не нужны, проще отключить XML-RPC целиком.
Блокировка на уровне nginx или Apache
Если вы хотите, чтобы запросы даже не попадали в WordPress, блокируйте xmlrpc.php на веб-сервере. Это особенно полезно, когда сайт регулярно получает мусорный трафик или попытки брутфорса.
nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации проверьте синтаксис и перезагрузите nginx. Не забывайте, что правила могут конфликтовать с другими location-блоками, если они настроены неаккуратно.
Apache
<Files "xmlrpc.php">
Require all denied
</Files>Если у вас старый стек с mod_access_compat, синтаксис может отличаться, но смысл тот же: запретить прямой доступ к файлу.
Проверка результата после внедрения
После отключения проверьте не только сам файл, но и реальные сценарии. Ошибка здесь обычно проявляется не сразу, а позже — когда кто-то пытается опубликовать запись из внешнего клиента или когда сервис мониторинга начинает ругаться на недоступность endpoint’а.
- Откройте
/xmlrpc.phpв браузере или черезcurlи проверьте код ответа. - Попробуйте войти в админку и создать запись обычным способом.
- Если используется мобильное приложение WordPress, проверьте синхронизацию.
- Если есть интеграции с внешними сервисами, сделайте тестовую публикацию.
- Посмотрите логи сервера: запросы к
xmlrpc.phpдолжны исчезнуть или получать отказ.
Если вы отключали XML-RPC через код, убедитесь, что mu-plugin загружается. Если через сервер — что правило реально применилось к нужному виртуальному хосту.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Причина почти всегда одна: Jetpack или другой сервис использовал XML-RPC для части функций. Решение — либо вернуть доступ, либо перевести интеграцию на другой способ подключения, если он поддерживается конкретным сервисом.
Поставили плагин, но запросы всё равно проходят
Некоторые плагины только отключают методы внутри WordPress, но не блокируют сам файл на уровне сервера. Если вам нужна жёсткая защита, добавьте правило в nginx/Apache.
Сломали публикацию через сторонний клиент
Значит, клиент действительно работал через XML-RPC. Тут не помогает «починить WordPress» — нужно либо вернуть XML-RPC, либо отказаться от этого клиента.
Отключили pingback, но не проверили комментарии
Pingback и комментарии — разные механизмы, но их часто путают. Если у вас есть старые материалы с внешними ссылками, убедитесь, что вы не отключили что-то лишнее в процессе.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC — не универсальная защита, а один из шагов. Если цель — уменьшить поверхность атаки, проверьте ещё несколько вещей:
- закрыт ли доступ к
wp-login.phpдля ботов; - есть ли ограничение попыток входа;
- включён ли актуальный кеш страниц;
- не торчит ли лишняя информация в заголовках и мета-тегах;
- не используются ли старые плагины, которые сами открывают лишние endpoint’ы.
Если вам нужен более широкий набор технических настроек без ручной правки десятка мелких параметров, можно посмотреть в сторону Clearfy Pro: он закрывает часть типовых задач по чистке WordPress и отключению лишнего. Подробности есть на странице плагина.
Когда XML-RPC лучше не трогать
Если у вас есть рабочая интеграция, которая завязана именно на XML-RPC, отключение без замены создаст больше проблем, чем пользы. В таком случае лучше ограничить доступ на уровне сервера по IP, включить дополнительную защиту авторизации и отдельно мониторить обращения к endpoint’у. Это безопаснее, чем ломать рабочий сценарий ради абстрактного «усиления безопасности».
Практический критерий простой: если после отключения у вас не осталось ни одного реального сценария использования XML-RPC, значит решение принято правильно. Если хотя бы один сервис перестал работать — сначала найдите замену, потом отключайте.