Как отключить XML-RPC в WordPress и защитить сайт от брутфорса

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

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

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

Сначала проверьте не «по совету из интернета», а по факту использования. На практике XML-RPC нужен редко:

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

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

Быстрая диагностика проблемы

Посмотрите логи веб-сервера или WAF. Типичный признак — большое число запросов к /xmlrpc.php с одинаковыми или похожими параметрами. Ещё один сигнал — попытки авторизации, которые не видны в стандартной статистике WordPress, но создают нагрузку на PHP и базу.

Если у вас есть доступ к командной строке на сервере, можно быстро проверить, отвечает ли endpoint:

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

Ответ 200 OK или даже 405 Method Not Allowed ещё не означает, что всё безопасно. Важно именно то, что endpoint доступен извне и может принимать запросы.

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

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

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

Самый предсказуемый способ — скрыть XML-RPC на уровне WordPress. Добавьте код в functions.php дочерней темы или, лучше, в небольшой mu-plugin, чтобы он не потерялся при обновлении темы.

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

Этот вариант отключает сам механизм XML-RPC внутри WordPress. Для большинства сайтов этого достаточно. Если хотите не только отключить функциональность, но и отдать 403 на прямой запрос к xmlrpc.php, можно добавить отдельную проверку:

<?php
add_action( 'init', function () {
    if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
        status_header( 403 );
        exit;
    }
} );

Я бы использовал первый вариант как базовый, а второй — только если понимаете, как это повлияет на внешние интеграции и отладку.

Вариант 2: отключение через mu-plugin

Если не хотите править тему, создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Mu-plugin загружается автоматически и не зависит от активации в админке.

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

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

Вариант 3: запрет на уровне сервера

Если цель — не просто выключить функциональность, а остановить лишние запросы до запуска PHP, ограничьте доступ к xmlrpc.php на уровне веб-сервера. Для Apache можно использовать правило в .htaccess:

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

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

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

Этот способ особенно полезен, если на сайт идёт заметный поток мусорных запросов. Но вносить такие правки нужно только если вы понимаете, как у вас устроена конфигурация и кто её потом будет поддерживать.

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

1. Проверьте, используется ли XML-RPC в реальных сценариях: мобильные клиенты, внешняя публикация, старые интеграции.
2. Сделайте резервную копию файлов и базы, если меняете серверную конфигурацию или код в продакшене.
3. Выберите один способ отключения: код, mu-plugin или правило сервера.
4. Внесите изменение и очистите кеш, если у вас есть page cache, object cache или CDN.
5. Проверьте ответ /xmlrpc.php снаружи сайта.
6. Посмотрите логи в течение ближайшего времени: запросы должны перестать доходить до PHP или получать отказ.

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

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

Проверка должна быть не «страница открывается», а именно по endpoint. Самый простой тест:

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

Что считать нормальным результатом:

• если вы отключали через xmlrpc_enabled, WordPress не должен обрабатывать XML-RPC-запросы как рабочие;
• если вы закрыли доступ на сервере, запрос должен получать 403 Forbidden или аналогичный отказ;
• в логах веб-сервера должно стать меньше обращений к xmlrpc.php либо они должны завершаться отказом до PHP.

Дополнительно проверьте админку и публикацию записей обычным способом. Это важно, чтобы не перепутать отключение XML-RPC с более общей проблемой авторизации или REST API.

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

Отключили XML-RPC, но забыли про старую интеграцию

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

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

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

Добавили правило в неправильный конфиг

Для nginx и Apache правила разные. Если вы вставили <Files> в конфиг nginx или location в .htaccess, ничего не заработает. Сначала уточните, какой веб-сервер реально обслуживает сайт.

Не очистили кеш

После изменения правил кеш страницы или CDN может показывать старую картину. Очистите кеш на всех уровнях: плагин кеширования, серверный кеш, CDN, браузер.

Что делать, если XML-RPC всё-таки нужен

Иногда полностью отключать XML-RPC нельзя. Тогда лучше не оставлять его открытым без ограничений. Минимальный набор мер:

• ограничить доступ по IP, если интеграция работает с фиксированного адреса;
• включить защиту от брутфорса на уровне WAF или fail2ban;
• отдельно проверить, не используется ли system.multicall для массовых попыток входа;
• следить за логами и нагрузкой после любых изменений.

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

Практический чек-лист перед выкладкой на продакшен

• Проверили, что XML-RPC не нужен текущим интеграциям.
• Выбрали один способ отключения и не смешали сразу несколько без необходимости.
• Сделали бэкап перед правкой кода или конфигурации.
• Очистили кеши после изменений.
• Проверили ответ /xmlrpc.php через curl или браузер.
• Посмотрели логи и убедились, что лишние запросы не идут в PHP.

Если после отключения сайт работает как раньше, а запросы к xmlrpc.php больше не обрабатываются, значит, задача решена правильно: без лишних плагинов, без догадок и без побочных эффектов.