Если в логах регулярно светится /xmlrpc.php, а сайт получает лишние запросы, отключение XML-RPC — нормальная техническая мера. Но делать это надо аккуратно: у части сайтов через XML-RPC до сих пор работают Jetpack, старые мобильные клиенты, публикация по удалёнке и некоторые внешние сервисы.
Ниже — рабочая схема: сначала диагностика, потом отключение на уровне WordPress или сервера, затем проверка, что нужные сценарии не отвалились.
Когда XML-RPC действительно стоит отключать
XML-RPC имеет смысл закрывать, если вы видите один или несколько признаков:
- в access-логах много запросов к
/xmlrpc.phpот ботов и сканеров; - на сайт идут попытки подбора пароля через
system.multicall; - вы не используете Jetpack, мобильное приложение WordPress и удалённую публикацию;
- хостинг или WAF уже ругается на всплески запросов к этому файлу.
Если у вас есть интеграции, которые завязаны на XML-RPC, сначала проверьте их список. Иначе можно получить «тихий» сбой: сайт живой, но публикации или синхронизация перестали работать.
Диагностика: кто обращается к xmlrpc.php
Перед изменениями полезно понять масштаб проблемы. На обычном shared-хостинге достаточно посмотреть access-лог. На VPS можно быстро отфильтровать запросы к нужному файлу:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если логов много, смотрите не только факт обращения, но и частоту. Повторяющиеся POST-запросы с одинаковых IP обычно означают перебор или автоматический скан.
Ещё один полезный тест — проверить, отвечает ли файл сейчас:
curl -I https://example.com/xmlrpc.phpНормальный ответ сам по себе не проблема. Важно, чтобы вы понимали, нужен ли этот endpoint вашему сайту вообще.
Способы отключения: код, сервер, плагин
Есть три практических варианта. Выбор зависит от того, где вы хотите контролировать доступ.
| Способ | Когда подходит | Минус |
|---|---|---|
| Код в WordPress | Нужно быстро отключить без правок конфигурации сервера | Запрос всё равно доходит до WordPress |
| Правило на сервере | Есть доступ к Nginx/Apache и нужен более жёсткий запрет | Нужно аккуратно не задеть другие правила |
| Плагин безопасности | Нужно управлять настройкой из админки | Лишняя зависимость от плагина |
Вариант 1. Отключить XML-RPC через код
Самый простой способ — запретить использование XML-RPC фильтром xmlrpc_enabled. Добавьте код в functions.php дочерней темы или в свой мини-плагин:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключает сам механизм XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно.
Если вам нужно не просто отключить функциональность, а ещё и убрать типовые атаки на xmlrpc.php, можно дополнительно отдавать 403 на уровне шаблона загрузки файла. Но тут важно не сломать легитимные сценарии, если они есть.
Вариант 2. Закрыть xmlrpc.php на уровне Nginx
Если у вас Nginx, безопаснее блокировать запросы до попадания в WordPress. Для отдельного сайта можно добавить правило в конфигурацию:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После этого запросы к файлу будут получать отказ ещё на уровне веб-сервера. Это снижает нагрузку и убирает лишний шум в логах.
Если сайт работает через Apache, аналогичный эффект можно получить через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>После правки конфигурации не забудьте проверить, что правила применились именно к нужному виртуальному хосту, а не к другому сайту на сервере.
Вариант 3. Использовать плагин безопасности
Если вам удобнее управлять настройкой из админки, можно использовать плагин, который умеет отключать XML-RPC. Важно только не ставить несколько плагинов с одинаковой функцией: они часто дублируют друг друга и усложняют диагностику.
Для сайтов, где параллельно нужно чистить технические дубли, отключать лишние скрипты и наводить порядок в SEO-настройках, удобнее держать это в одном инструменте, а не собирать из нескольких разных плагинов. Например, в Clearfy Pro есть набор функций для технической чистки WordPress, но использовать его стоит только если вам реально нужен весь этот набор, а не одна галочка.
Пошаговое решение без лишнего риска
- Проверьте, используется ли XML-RPC в вашем проекте: Jetpack, мобильное приложение WordPress, внешние публикации, старые интеграции.
- Сделайте резервную копию конфигурации сервера или файла темы, если вносите правки вручную.
- Выберите один способ блокировки: код в WordPress или правило на сервере.
- Внедрите изменение только на одном сайте, если у вас мультисайт или несколько виртуальных хостов.
- Проверьте ответ
/xmlrpc.phpи тестовые сценарии, которые завязаны на удалённую публикацию.
Если вы отключаете через код, лучше вынести это в отдельный мини-плагин. Так настройка не исчезнет при смене темы:
<?php
/*
Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой вариант проще сопровождать, чем правка functions.php, особенно если тема обновляется регулярно.
Как проверить, что всё сработало
После внедрения проверьте не только код ответа, но и реальные сценарии.
- Откройте
https://example.com/xmlrpc.phpв браузере или черезcurl -I. - Убедитесь, что ответ стал
403,404или другой ожидаемый отказ, а не обычная обработка WordPress. - Если используете Jetpack, проверьте подключение и синхронизацию.
- Если публикуете через внешний сервис, сделайте тестовую отправку записи.
- Посмотрите access-лог через 10–15 минут: запросы должны либо исчезнуть, либо перестать доходить до PHP.
Для более точной проверки можно отправить тестовый POST-запрос:
curl -X POST https://example.com/xmlrpc.php -d '<methodCall><methodName>system.listMethods</methodName></methodCall>'Если блокировка настроена корректно, вы не должны получить нормальный XML-RPC-ответ со списком методов.
Частые ошибки и как их исправить
Отключили XML-RPC, а Jetpack перестал подключаться
Это ожидаемо, если Jetpack всё ещё использует XML-RPC в вашем сценарии. Решение простое: либо возвращаете доступ, либо переводите интеграцию на другой способ, если он доступен в вашей конфигурации.
Поставили правило в Nginx, но запросы всё равно проходят
Обычно причина в том, что правило добавили не в тот server-блок или оно перекрывается другим location. Проверьте конфигурацию через nginx -T и убедитесь, что именно этот сайт обслуживается нужным виртуальным хостом.
Использовали несколько плагинов безопасности сразу
Один плагин отключает XML-RPC, второй пытается его ограничить, третий добавляет firewall-правила. В итоге непонятно, что именно ломает интеграцию. Оставьте один источник правды для этой настройки.
Скрыли проблему, но не убрали нагрузку
Если блокировка сделана только на уровне WordPress, бот всё равно тратит ресурсы на подключение к PHP. Для сайтов под нагрузкой лучше закрывать xmlrpc.php на сервере.
Безопасность и производительность: что ещё проверить рядом
Отключение XML-RPC — не замена нормальной защите входа. Если у вас слабые пароли или открыт /wp-login.php без ограничений, боты найдут другой путь.
Практически полезно сразу проверить:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- актуальность ядра, темы и плагинов;
- наличие WAF или хотя бы базовых правил на уровне хостинга;
- логи ошибок PHP после изменения конфигурации.
Если вы уже наводите порядок в технических настройках WordPress, имеет смысл смотреть на сайт шире: убрать лишние дубли, отключить ненужные функции и не держать в активном состоянии то, чем вы не пользуетесь. Но каждую такую правку лучше проверять отдельно, а не вносить пачкой.
В итоге рабочая схема простая: сначала понять, нужен ли XML-RPC, потом отключить его там, где это безопасно для проекта, и после этого проверить реальные интеграции, а не только код ответа.