Как отключить XML-RPC в WordPress без поломки Jetpack и мобильных приложений

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

Если задача не в том, чтобы просто «выключить что-нибудь лишнее», а в том, чтобы убрать лишнюю поверхность атаки и не сломать рабочие сценарии, сначала стоит понять, кто вообще ходит в /xmlrpc.php.

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

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

Отключение оправдано, если:

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

Если же сайт синхронизируется со сторонним сервисом, публикуется из мобильного приложения или завязан на старую интеграцию, отключать XML-RPC без проверки не стоит.

Диагностика: кто использует xmlrpc.php

Перед изменениями проверьте, есть ли реальные обращения к этому файлу. Самый простой способ — посмотреть access log веб-сервера. На Nginx это обычно лог запросов сайта, на Apache — access.log. Ищите строки с /xmlrpc.php.

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

Если логов нет под рукой, можно временно включить мониторинг на уровне сервера или посмотреть статистику в панели хостинга. Важны не только сами запросы, но и их источник: IP, user-agent, частота, коды ответа.

Что считать признаком зависимости

• регулярные успешные POST-запросы к /xmlrpc.php;
• запросы от Jetpack или других известных сервисов;
• ошибки авторизации, которые повторяются по расписанию;
• обращения после публикации записи, если у вас настроены внешние интеграции.

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

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

Выбор зависит от того, где вам удобнее контролировать поведение: в коде темы/плагина, на уровне сервера или через плагин безопасности. Ниже — варианты с разными компромиссами.

Вариант 1: отключить через код WordPress

Это удобный способ, если вы управляете сайтом через тему или mu-plugin. Добавьте код в functions.php дочерней темы или в отдельный must-use плагин.

add_filter( 'xmlrpc_enabled', '__return_false' );

Такой вариант отключает XML-RPC на уровне WordPress. Если кто-то обратится к /xmlrpc.php, он получит отказ уже после загрузки окружения.

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

Вариант 2: заблокировать доступ на уровне Nginx

Если сайт под вашим контролем и вы можете менять конфиг, лучше отрезать запросы раньше, чем они дойдут до PHP. Для Nginx это обычно выглядит так:

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

Такой блок полезен, когда на сайт идёт много мусорных запросов. PHP-FPM не будет тратить ресурсы на обработку, а в логах станет тише. Но перед применением убедитесь, что XML-RPC нигде не используется, иначе вы сломаете интеграцию на уровне сервера.

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

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

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

Пошаговое решение без сюрпризов

1. Проверьте логи и убедитесь, что легитимных обращений к /xmlrpc.php нет.
2. Проверьте Jetpack, мобильные приложения, внешние публикации и старые интеграции.
3. Выберите способ отключения: код, сервер или плагин.
4. Внесите изменение сначала на staging, а не на боевом сайте.
5. Проверьте ответ /xmlrpc.php и убедитесь, что нужные сценарии не сломались.
6. После выката ещё раз посмотрите access log и ошибки в журнале сайта.

Если у вас есть доступ только к WordPress-админке, начните с фильтра xmlrpc_enabled. Если доступ к серверу есть и сайт под атакой ботов, лучше закрыть URL на уровне веб-сервера.

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

Проверка должна быть простой и повторяемой. Не ограничивайтесь тем, что «страница открывается». Нужно убедиться, что именно XML-RPC больше не отвечает как раньше.

Проверка через curl

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

Если вы отключили доступ на уровне сервера, в ответе обычно будет 403 или другой отказ в зависимости от конфигурации. Если отключали через WordPress-фильтр, поведение может отличаться, но сам сервис не должен принимать рабочие XML-RPC-запросы.

Проверка через тестовый запрос

Можно отправить минимальный XML-RPC payload и посмотреть, что вернёт сайт. Для живой проверки используйте отдельный тестовый стенд или staging.

curl -X POST https://example.com/xmlrpc.php \
  -H "Content-Type: text/xml" \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

Если XML-RPC отключён корректно, вы не должны получить нормальный список методов. Важно смотреть не только HTTP-код, но и содержание ответа.

Что ещё проверить после внедрения

• Jetpack: подключение, статистику, публикацию и синхронизацию;
• внешние клиенты, если они были;
• ошибки 403/405/500 в логах после изменения;
• нагрузку на сервер, если до этого был поток мусорных запросов.

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

Отключили XML-RPC, не проверив Jetpack

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

Заблокировали URL в Nginx, но забыли про staging

На тестовом стенде всё может работать иначе: другой конфиг, другой кеш, другие плагины. Если вы проверили только боевой сайт, а staging не трогали, можно пропустить зависимость, которая всплывёт после деплоя.

Сделали запрет через .htaccess и сломали правила выше

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

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

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

Безопасность и производительность: что даёт отключение на практике

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

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

Если вам нужен более широкий технический аудит сайта, имеет смысл проверить не только XML-RPC, но и дубли, лишние эндпоинты, неиспользуемые фичи темы и плагинов. В таких задачах полезны инструменты вроде Clearfy Pro, если нужен централизованный контроль над техничкой и чисткой сайта: https://wpshop.ru/plugins/clearfy.

Короткий чек-лист перед отключением

• Проверены логи на реальные обращения к /xmlrpc.php.
• Понятно, используется ли Jetpack или внешняя публикация.
• Выбран способ отключения: код, сервер или плагин.
• Изменение сначала протестировано на staging.
• После внедрения проверен ответ xmlrpc.php и логи ошибок.

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