Если в логах регулярно появляются запросы к /xmlrpc.php, а в админке нет явной причины держать этот интерфейс открытым, его обычно имеет смысл закрыть. На практике XML-RPC чаще всего нужен только для старых внешних клиентов, Jetpack и некоторых мобильных сценариев. Во всех остальных случаях это лишняя поверхность атаки: по ней удобно проверять доступность сайта, подбирать логины и запускать массовые запросы.
Ниже — рабочая схема: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его без лишних побочных эффектов и как проверить, что блокировка действительно сработала.
Когда XML-RPC лучше отключить, а когда не трогать
Сначала стоит не ломать, а проверить зависимость. Если сайт не использует Jetpack, мобильное приложение WordPress, удалённую публикацию через старые клиенты или внешние сервисы, которые явно требуют XML-RPC, отключение обычно безопасно. Если же вы не уверены, посмотрите, есть ли обращения к этому файлу в логах веб-сервера или в отчётах безопасности.
Признаки, что XML-RPC вам не нужен
- в логах есть регулярные POST-запросы к
/xmlrpc.phpбез понятной бизнес-логики; - сайт не использует Jetpack и не публикуется из внешних клиентов;
- в админке нет интеграций, которые прямо завязаны на XML-RPC;
- в панели хостинга или WAF видны попытки перебора через XML-RPC.
Когда отключать нельзя без проверки
Если сайт подключён к Jetpack, использует мобильное приложение WordPress или старые внешние инструменты публикации, сначала проверьте, что они не зависят от XML-RPC. Иначе после блокировки можно получить неочевидные ошибки синхронизации, которые сложно диагностировать задним числом.
Диагностика: как понять, что именно атакуют через xmlrpc.php
Самый простой способ — посмотреть access log. Ищите запросы вида POST /xmlrpc.php. Если их много и они идут с разных IP, это типичный шум брутфорса или сканирования. Если запросы идут с одного и того же сервиса, это уже повод проверить конкретную интеграцию.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если доступа к логам нет, можно временно поставить плагин для безопасности или мониторинга запросов, но для точной диагностики логи надёжнее. Важно не путать XML-RPC с REST API: это разные механизмы, и отключение одного не выключает другой.
Как отключить XML-RPC: сравнение подходов
| Способ | Что делает | Плюсы | Минусы |
|---|---|---|---|
| Код в теме или mu-plugin | Отключает XML-RPC на уровне WordPress | Контролируемо, без лишних плагинов | Нужно аккуратно добавить код |
| Плагин безопасности | Блокирует доступ через настройки | Просто включить | Ещё один плагин в стеке |
| Правило на уровне сервера | Режет запросы до WordPress | Снимает нагрузку раньше PHP | Нужен доступ к конфигу nginx/apache |
Если у вас есть доступ к коду, самый предсказуемый вариант — отключить XML-RPC через фильтр. Если нужен более жёсткий барьер, добавьте блокировку на уровне веб-сервера. В идеале эти меры можно сочетать, но не стоит начинать с трёх разных плагинов одновременно.
Пошаговое решение через код
Для большинства сайтов достаточно небольшого сниппета. Его можно добавить в functions.php дочерней темы, но практичнее вынести в mu-plugin, чтобы он не зависел от смены темы.
Вариант 1: отключить XML-RPC полностью
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант выключает сам механизм XML-RPC на уровне WordPress. После этого запросы к xmlrpc.php не должны выполнять полезную работу, даже если файл физически доступен.
Вариант 2: оставить только нужные методы
Если вам нужна часть функциональности, можно ограничить список методов. Это уже более тонкая настройка, но она имеет смысл только если вы точно понимаете, какой клиент и какой метод использует.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['system.multicall'] );
unset( $methods['pingback.ping'] );
return $methods;
} );На практике чаще всего отключают именно pingback.ping и system.multicall, потому что они часто участвуют в злоупотреблениях. Но если задача — именно убрать поверхность атаки, а не тонко ограничить функциональность, проще отключить XML-RPC целиком.
Блокировка на уровне сервера
Если сайт часто атакуют, лучше не доводить запрос до PHP. Для nginx можно вернуть 403 на /xmlrpc.php прямо в конфиге сайта.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess или конфиге виртуального хоста. Смысл тот же: запрос должен быть остановлен до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Если у вас общий хостинг и нет доступа к конфигу сервера, остаётся вариант с кодом или плагином. Но даже в этом случае полезно проверить, не даёт ли хостинг встроенную защиту от массовых запросов к XML-RPC.
Как проверить, что решение сработало
После внедрения не ограничивайтесь открытием страницы в браузере. Нужно проверить именно поведение /xmlrpc.php.
- Откройте
/xmlrpc.phpв браузере: при жёсткой блокировке должен быть отказ в доступе или пустой ответ без рабочего интерфейса. - Проверьте логи сервера: запросы к этому файлу не должны доходить до WordPress как обычные PHP-обработки.
- Если использовали код, временно включите отладку и убедитесь, что сайт не пишет ошибок, связанных с XML-RPC.
- Если есть Jetpack или внешний клиент, проверьте их статус отдельно, а не только главную страницу сайта.
Для быстрой проверки с консоли можно отправить тестовый запрос:
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали на уровне сервера, ответ должен быть отказом или кодом, который соответствует вашей политике доступа. Если отключали только фильтром WordPress, ответ может отличаться, но сам механизм должен перестать выполнять полезные действия.
Частые ошибки и почему они возникают
Отключили XML-RPC, а Jetpack перестал синхронизироваться
Это ожидаемо, если Jetpack использовался для связи с сайтом через XML-RPC. Решение простое: либо вернуть доступ, либо перейти на другой способ интеграции, если он доступен в вашем сценарии. Не надо оставлять поломанный Jetpack «на потом» — такие ошибки потом сложно отличить от проблем сети или авторизации.
Поставили плагин, но запросы продолжают идти
Часто плагин отключает функциональность внутри WordPress, но сам файл остаётся доступным на уровне веб-сервера. В результате нагрузка от ботов никуда не девается. Если атака массовая, лучше добавить блокировку на nginx или Apache.
Сломали удалённую публикацию старым клиентом
Некоторые старые приложения и сервисы до сих пор используют XML-RPC для публикации записей. Если такой сценарий у вас есть, сначала проверьте его в тестовой среде или на staging-копии. Иначе можно обнаружить проблему уже после того, как контент перестанет уходить в продакшен.
Практические советы по безопасности и производительности
Отключение XML-RPC — не замена нормальной защите входа в админку. Если сайт регулярно атакуют, имеет смысл дополнительно проверить:
- сложность паролей и наличие двухфакторной аутентификации;
- ограничение попыток входа;
- наличие актуальных обновлений ядра, темы и плагинов;
- логи 403/401 и частоту обращений к подозрительным URL;
- нет ли лишних плагинов, которые расширяют поверхность атаки без пользы.
Если вам нужен более широкий набор технических чисток и отключений, иногда удобнее использовать специализированный набор настроек вроде Clearfy Pro: он помогает убрать часть лишнего функционала и сократить количество технического мусора в WordPress. Но даже в этом случае блокировку XML-RPC лучше проверять отдельно, а не считать её автоматически включённой.
Главная идея простая: если XML-RPC не нужен, его лучше закрыть на уровне WordPress и сервера, а потом проверить логи и зависимые сервисы. Тогда вы уменьшите шум от ботов и не будете ловить побочные эффекты вслепую.