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

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

Если задача именно практическая — убрать лишнюю точку входа для брутфорса и при этом не сломать рабочие сценарии, лучше идти по схеме: сначала диагностика, потом ограничение доступа, затем проверка логов и только после этого жёсткое отключение.

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

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

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

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

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

Что проверить в первую очередь

• есть ли обращения от Jetpack;
• используется ли мобильное приложение WordPress;
• есть ли внешние сервисы автопостинга или мониторинга;
• не завязаны ли интеграции на удалённую публикацию;
• есть ли массовые POST-запросы с одинаковым user-agent и IP.

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

Пошаговое решение: как отключить XML-RPC безопасно

Есть три рабочих подхода: через плагин, через код и на уровне веб-сервера. Для большинства сайтов самый предсказуемый вариант — код в functions.php дочерней темы или в небольшом mu-plugin. Если нужен быстрый и управляемый способ без правки темы, можно использовать плагин безопасности, но важно понимать, что он делает под капотом.

Подход	Плюсы	Минусы
Плагин безопасности	Быстро, без кода, удобно для типовых сайтов	Лишняя зависимость, не всегда прозрачно, что именно отключено
Код в mu-plugin	Надёжно, не зависит от темы, легко откатить	Нужен доступ к файлам и минимальная дисциплина при деплое
Nginx/Apache	Режет запросы раньше WordPress, экономит ресурсы	Нужно аккуратно тестировать, особенно если есть внешние интеграции

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

Если вы уверены, что endpoint не нужен, добавьте фильтр xmlrpc_enabled. Это самый понятный способ для WordPress.

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

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

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

Если сайт под Nginx, можно отрезать запросы к xmlrpc.php до передачи в PHP. Это полезно, когда endpoint точно не нужен и вы хотите снизить нагрузку от мусорных запросов.

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

Такой вариант хорош как дополнительный слой защиты, но перед включением убедитесь, что ни один сервис не обращается к этому файлу. Иначе вы получите труднообъяснимую поломку синхронизации, а не просто «усиление безопасности».

Вариант 3: ограничить, а не выключать полностью

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

На уровне сервера это делается точечно, но такой сценарий требует аккуратного сопровождения: если IP сервиса изменится, интеграция сломается. Для долгоживущих проектов это компромисс, а не универсальное решение.

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

После отключения не ограничивайтесь тем, что страница /xmlrpc.php «не открывается». Нужно проверить, что сайт ведёт себя ожидаемо и не потерял нужные функции.

• Откройте /xmlrpc.php в браузере или через curl и убедитесь, что доступ закрыт или возвращается ожидаемый статус.
• Проверьте вход в админку и публикацию записей обычным способом.
• Если используется Jetpack, проверьте его статус в панели плагина.
• Если есть мобильное приложение WordPress или внешняя интеграция, выполните тестовую публикацию.
• Посмотрите access.log: запросы к xmlrpc.php должны либо исчезнуть, либо получать отказ без нагрузки на PHP.

Для быстрой проверки удобно использовать команду:

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

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

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

Отключили XML-RPC, а потом перестал работать Jetpack

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

Закрыли endpoint на сервере, но забыли про внешние сервисы

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

Использовали плагин, который только скрывает проблему

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

Проверили только браузер, но не проверили логин и публикацию

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

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

• Проверить access.log на обращения к /xmlrpc.php.
• Уточнить, используется ли Jetpack.
• Проверить мобильные клиенты WordPress.
• Сверить внешние сервисы автопостинга и мониторинга.
• Выбрать уровень блокировки: WordPress, веб-сервер или оба.
• Сделать быстрый откатный план.
• После внедрения проверить публикацию, вход и интеграции.

Что ещё можно сделать для безопасности

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

Для производительности важно ещё и то, что блокировка на уровне веб-сервера экономит ресурсы раньше, чем запрос дойдёт до PHP. На нагруженных сайтах это заметно именно по мусорным обращениям, а не по «ускорению в вакууме».

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