XML-RPC в WordPress до сих пор часто остаётся включённым по умолчанию, хотя на большинстве сайтов он не нужен. Если вы не используете старые мобильные клиенты, Jetpack в режиме, который требует XML-RPC, или внешние сервисы, завязанные именно на этот протокол, его лучше закрыть. Это не «магическая защита», но полезное уменьшение поверхности атаки: меньше точек для перебора паролей, pingback-спама и лишних запросов к сайту.
Ниже — рабочие способы отключения, как проверить результат и где чаще всего ошибаются. Если задача стоит не «поставить галочку в плагине», а именно убрать XML-RPC без побочных эффектов, лучше идти по шагам.
Когда XML-RPC действительно стоит отключать
Сначала проверьте, нужен ли он вам вообще. На живых проектах XML-RPC обычно оставляют по инерции, а потом удивляются лишним запросам и попыткам авторизации. Если сайт управляется только через обычную админку WordPress, REST API и современный мобильный клиент не используются, отключение обычно безопасно.
Сценарии, где отключение оправдано
- на сайте нет внешних сервисов, которые публикуют записи через XML-RPC;
- не используется старый мобильный клиент WordPress, завязанный на XML-RPC;
- Jetpack не требует именно XML-RPC в вашей конфигурации;
- в логах видны массовые запросы к
/xmlrpc.php; - нужно сократить риск перебора логина через мульти-колл метод
system.multicall.
Когда лучше не отключать сразу
Если у вас есть интеграции с публикацией из внешних систем, проверьте их документацию. Иногда сервисы используют не REST API, а именно XML-RPC. В таком случае сначала тестируйте на staging-окружении или хотя бы на коротком окне с мониторингом логов.
Диагностика: как понять, что XML-RPC сейчас открыт
Самый простой тест — открыть /xmlrpc.php в браузере или через curl. Если файл доступен, это ещё не значит, что он уязвим, но значит, что endpoint отвечает. Для практической проверки важен именно ответ сервера.
curl -I https://example.com/xmlrpc.phpОбычно вы увидите 200 OK, 405 Method Not Allowed или другой ответ, зависящий от конфигурации. Для нас важен сам факт, что запрос не блокируется на уровне сайта или сервера.
Можно проверить и содержимое ответа:
curl -s https://example.com/xmlrpc.php | headЕсли XML-RPC включён, WordPress обычно отдаёт текст о том, что сервер принимает только POST-запросы. Это нормальное поведение для активного endpoint.
Как отключить XML-RPC в WordPress: рабочие варианты
Есть три практических подхода: кодом в теме или mu-plugin, через сервер, через плагин. Для продакшена чаще всего удобнее код или сервер, потому что это не зависит от интерфейса админки.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в mu-plugin | Не зависит от темы, легко контролировать в Git | Нужен доступ к файлам | Если нужен предсказуемый результат |
| Правило на сервере | Блокирует запрос раньше WordPress | Нужно править конфиг веб-сервера | Если хотите снизить нагрузку и закрыть endpoint на уровне сервера |
| Плагин безопасности | Быстро включить без кода | Лишняя зависимость от плагина | Если нет доступа к серверу или нужен быстрый временный вариант |
Вариант 1: отключить XML-RPC кодом
Самый аккуратный способ — добавить фильтр xmlrpc_enabled. Лучше не в functions.php активной темы, а в маленький mu-plugin, чтобы настройка не пропала после смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter('xmlrpc_enabled', '__return_false');Файл положите в wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её. WordPress подхватывает такие плагины автоматически.
Если нужно не просто выключить XML-RPC, а ещё и явно вернуть 403 на прямой запрос, можно добавить отдельную проверку:
<?php
/**
* Plugin Name: Disable XML-RPC and block direct access
*/
add_filter('xmlrpc_enabled', '__return_false');
add_action('init', function () {
if (defined('XMLRPC_REQUEST') && XMLRPC_REQUEST) {
status_header(403);
exit;
}
});Второй вариант полезен, если вы хотите, чтобы endpoint не просто «не работал», а явно блокировался. Но в большинстве случаев достаточно одного фильтра.
Вариант 2: закрыть xmlrpc.php на уровне сервера
Если у вас Apache, можно добавить правило в .htaccess. Это блокирует запрос до загрузки WordPress и экономит ресурсы.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика другая — правило добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить веб-сервер. На Nginx это обычно nginx -t перед reload.
Вариант 3: отключить через плагин
Если вы не хотите трогать код, используйте плагин безопасности, который умеет отключать XML-RPC. Это рабочий путь, но следите, чтобы плагин не делал лишнего и не конфликтовал с другими настройками. Если у вас уже стоит комплексный плагин для технической чистки сайта, например Clearfy Pro, проверьте, не дублируете ли вы одну и ту же функцию в нескольких местах.
Плагин удобен для быстрого старта, но для долгой жизни проекта код или сервер обычно надёжнее: меньше зависимостей, проще ревью, легче переносить между окружениями.
Проверка результата после внедрения
После отключения не ограничивайтесь «в админке ошибок нет». Нужно проверить endpoint снаружи, как его видит реальный клиент.
Мини-чек-лист проверки
- откройте
/xmlrpc.phpв браузере или черезcurl -I; - убедитесь, что ответ не содержит рабочего XML-RPC-баннера WordPress;
- проверьте, не ломается ли публикация из внешних сервисов, если они у вас есть;
- посмотрите access log: запросы к
/xmlrpc.phpдолжны либо исчезнуть, либо получать отказ; - если использовали серверное правило, убедитесь, что оно применяется именно к нужному виртуальному хосту.
Для более точной проверки можно отправить тестовый POST-запрос. Если XML-RPC отключён корректно, WordPress не должен обрабатывать метод как рабочий.
curl -s -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'Если в ответе нет нормального списка методов и endpoint закрыт, значит настройка сработала. На серверном уровне вы можете увидеть 403 или 404, в зависимости от выбранного способа.
Частые ошибки и как их исправить
Отключили в теме, а потом сменили шаблон
Если фильтр лежит в functions.php, он исчезнет при смене темы. Для технической настройки это плохое место. Перенесите код в mu-plugin или обычный плагин, который вы контролируете.
Закрыли только в WordPress, но endpoint всё равно отвечает
Фильтр xmlrpc_enabled отключает функциональность WordPress, но сам файл xmlrpc.php может продолжать отвечать на запросы. Если вам важно закрыть endpoint полностью, добавьте правило на сервере.
Сломали интеграцию, которая использовала XML-RPC
Такое бывает, если внешняя система публиковала записи через XML-RPC, а вы отключили его без проверки. Решение простое: либо вернуть доступ точечно, либо перевести интеграцию на REST API, если сервис это поддерживает.
Поставили несколько плагинов, которые делают одно и то же
Один плагин блокирует XML-RPC, другой пытается «усилить безопасность», третий добавляет свои правила в .htaccess. В итоге сложно понять, что именно работает. Оставляйте один источник правды: либо код, либо сервер, либо один плагин.
Что ещё имеет смысл проверить рядом с XML-RPC
Если вы уже занимаетесь технической чисткой сайта, посмотрите на соседние точки риска: лишние публичные endpoint’ы, дубли служебных страниц, доступ к wp-json там, где он не нужен, и старые плагины, которые давно не обновлялись. Не стоит отключать всё подряд, но полезно понимать, какие интерфейсы реально используются.
Для сайтов, где важна именно техническая гигиена, удобно держать такие изменения в одном месте: в mu-plugins, в конфиге сервера и в чек-листе деплоя. Тогда вы не забудете, что именно было закрыто и почему.
Если нужен более широкий набор настроек для чистки WordPress, отключения лишнего и контроля дублей, такие задачи часто решают через отдельный технический плагин или собственный mu-plugin, а не через правки в теме. Это проще поддерживать и легче проверять после обновлений.