Как отключить XML-RPC в WordPress и не сломать нужные интеграции

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

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

Когда XML-RPC действительно мешает

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

Диагностика: что проверить до отключения

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

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

Если вы не уверены, проще временно заблокировать доступ и проверить рабочие сценарии на тестовой копии сайта. На проде лучше не гадать.

Как отключить XML-RPC в WordPress через код

Самый чистый вариант — отключить обработку на уровне WordPress. Это удобно, если вы контролируете тему или небольшой mu-plugin. Метод не зависит от плагинов безопасности и не требует правки конфигурации сервера.

<?php
// В functions.php дочерней темы или в mu-plugin.
add_filter( 'xmlrpc_enabled', '__return_false' );

Этот фильтр отключает XML-RPC на уровне WordPress. В большинстве случаев этого достаточно, чтобы запросы к xmlrpc.php перестали обслуживаться.

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

Блокировка на уровне сервера

Если у вас Apache или Nginx, можно дополнительно закрыть сам файл xmlrpc.php. Это полезно как второй слой защиты, особенно если сайт часто атакуют перебором паролей.

Для Apache в .htaccess:

<Files xmlrpc.php>
    Require all denied
</Files>

Для Nginx обычно используют правило в конфигурации сайта:

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

Если вы не управляете сервером напрямую, этот шаг может быть недоступен. Тогда достаточно отключения через WordPress и правил в плагине безопасности или WAF, если он у вас есть.

Сравнение подходов: код, сервер, плагин

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

Пошаговое решение без лишнего риска

Ниже рабочая последовательность, которая помогает не сломать интеграции и быстро откатиться, если что-то пошло не так.

1. Проверьте, есть ли реальные зависимости от XML-RPC.
2. Сделайте бэкап или хотя бы сохраните доступ к FTP/SSH и админке.
3. Добавьте фильтр xmlrpc_enabled в дочернюю тему или mu-plugin.
4. Проверьте, что /xmlrpc.php больше не отвечает успешно.
5. Если доступ к серверу есть, закройте файл на уровне Nginx или Apache.
6. Проверьте внешние сервисы, которые могли использовать XML-RPC.

Для mu-plugin можно создать файл, например wp-content/mu-plugins/disable-xmlrpc.php:

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Такой вариант удобен тем, что он не зависит от темы и не потеряется при обновлении шаблона.

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

Проверка должна быть не «на глаз», а по факту ответа сервера. Самый простой способ — открыть /xmlrpc.php в браузере или отправить тестовый запрос через curl.

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

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

Дополнительно проверьте:

• не работают ли старые клиенты публикации;
• не появились ли ошибки в логах плагинов интеграции;
• не сломалась ли синхронизация с внешним сервисом, если она была;
• уменьшилось ли число обращений к xmlrpc.php в access-логах.

Если сайт использует мониторинг, полезно посмотреть не только код ответа, но и то, как изменился фон запросов после блокировки.

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

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

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

Добавили правило в .htaccess, но доступ всё равно есть

Причина обычно в том, что сайт работает не на Apache, а на Nginx, или правило стоит не в том месте. Ещё вариант — доступ к xmlrpc.php обрабатывается другим слоем, например CDN или WAF. В таком случае проверьте реальную схему веб-сервера, а не только файл .htaccess.

Отключили через фильтр, но в логах остались запросы

Это нормально: запросы продолжают приходить, просто WordPress их не обслуживает. Если цель — убрать сам трафик, нужна серверная блокировка или правило на уровне WAF/CDN.

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

Отключение XML-RPC — не замена нормальной защите входа. Если на сайте слабые пароли или открыт wp-login.php без ограничений, атакующий найдёт другой путь. Поэтому вместе с отключением XML-RPC имеет смысл проверить:

• сложность паролей у администраторов;
• наличие двухфакторной аутентификации, если она у вас внедрена;
• ограничение попыток входа;
• актуальность ядра, темы и плагинов;
• наличие лишних плагинов, которые давно не используются.

Если у вас уже есть плагин для технической чистки и SEO-оптимизации вроде Clearfy Pro, проверьте, не дублирует ли он часть этих настроек. Но не стоит включать несколько инструментов, которые одновременно пытаются управлять одним и тем же поведением: так сложнее понять, что именно сработало.

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