XML-RPC в WordPress давно нужен не всем, но на многих сайтах он по-прежнему открыт по умолчанию. Проблема не только в самом файле xmlrpc.php: вместе с ним часто остаются лишние точки входа для брутфорса, пинга внешних сервисов и старых интеграций, которые уже никто не использует. Если сайт не подключён к мобильному приложению WordPress, внешним публикациям через старые клиенты или специфическим сервисам, XML-RPC обычно можно отключить без потерь.
Ниже — не общая теория, а рабочий сценарий: как понять, нужен ли XML-RPC именно вам, как отключить его без поломки сайта и как проверить, что закрытие сработало.
Когда XML-RPC действительно мешает
Чаще всего его отключают по трём причинам: массовые попытки авторизации, лишняя нагрузка от запросов к xmlrpc.php и отсутствие реальной необходимости в старом протоколе. На практике это особенно заметно на сайтах, где включена защита логина, но в логах всё равно идут запросы к XML-RPC с подбором паролей через метод system.multicall.
Если у вас есть интеграции, проверьте их отдельно. XML-RPC может использоваться:
- мобильным приложением WordPress;
- старыми десктопными клиентами для публикации;
- некоторыми внешними сервисами автопостинга;
- редкими плагинами, которые до сих пор опираются на XML-RPC вместо REST API.
Быстрая диагностика перед отключением
Сначала посмотрите, есть ли реальные обращения к xmlrpc.php. Если у вас есть доступ к логам веб-сервера, достаточно фильтра по этому пути. На уровне WordPress можно временно добавить простой логирующий фильтр, но обычно это лишнее: серверные логи надёжнее и не создают дополнительной нагрузки на сайт.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20Если видите только сканирование и перебор методов, а не легитимные запросы от ваших сервисов, отключение XML-RPC оправдано.
Как отключить XML-RPC в WordPress
Есть два нормальных подхода: через код в теме или плагине и через серверную конфигурацию. Для большинства сайтов проще и безопаснее начать с кода: так вы не зависите от конкретного веб-сервера и можете быстро откатить изменение.
Вариант 1: отключение через фильтр
Добавьте код в functions.php дочерней темы или в свой небольшой плагин. Этот вариант отключает сам XML-RPC на уровне WordPress.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужен более жёсткий вариант, можно сразу отдавать 403 Forbidden при обращении к xmlrpc.php. Это полезно, когда на сайт идёт много автоматизированных запросов и вы хотите отрезать их раньше.
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );Но здесь есть нюанс: если WordPress уже начал обрабатывать запрос, часть логики всё равно будет задействована. Поэтому для высокой нагрузки лучше дополнить решение серверным правилом.
Вариант 2: блокировка на уровне сервера
Если сайт работает на Nginx, можно закрыть доступ к файлу напрямую. Это не замена WordPress-фильтру, а более ранний барьер.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files "xmlrpc.php">
Require all denied
</Files>Серверная блокировка полезна тем, что запросы даже не доходят до PHP. Это снижает лишнюю нагрузку и уменьшает шум в логах приложения.
Чем заменить старые сценарии, если XML-RPC нужен был для интеграций
Если вы отключаете XML-RPC не просто ради безопасности, а потому что хотите убрать устаревший протокол, заранее проверьте, чем заменить конкретный сценарий. Для публикации и чтения данных в WordPress уже давно есть REST API. Он не решает все задачи один в один, но для большинства современных интеграций это правильный путь.
| Подход | Когда подходит | Минус |
|---|---|---|
| Плагин/фильтр WordPress | Нужно быстро отключить XML-RPC без правок сервера | Запрос всё ещё доходит до PHP |
| Правило Nginx или Apache | Нужно отрезать точку входа раньше и снизить нагрузку | Требует доступа к конфигу сервера |
| REST API вместо XML-RPC | Есть внешняя интеграция или собственный клиент | Нужно перепроверить авторизацию и формат запросов |
Если у вас есть собственный код, который ходил в XML-RPC, лучше не оставлять его «как есть». Переведите интеграцию на REST API или хотя бы зафиксируйте, какие именно методы использовались, чтобы не потерять функциональность после отключения.
Проверка результата после внедрения
После отключения не ограничивайтесь визуальной проверкой в админке. Нужно убедиться, что точка входа реально закрыта и не ломает нужные сценарии.
- Откройте
/xmlrpc.phpв браузере или черезcurl. - Проверьте, что ответ не содержит рабочий XML-RPC-метод.
- Посмотрите логи сервера: запросы должны либо отсутствовать, либо получать отказ.
- Проверьте мобильное приложение WordPress и внешние сервисы, если они у вас были подключены.
Простой тест через командную строку:
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали файл на сервере, ожидаемый результат — 403 или другой отказ в доступе. Если использовали только фильтр WordPress, ответ может зависеть от конфигурации сервера, но сам XML-RPC не должен выполнять методы.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли старую интеграцию
Это самая неприятная ситуация: сайт вроде бы работает, но внешняя публикация или синхронизация перестаёт отвечать. Решение простое — сначала найти, кто именно использует XML-RPC, и только потом закрывать доступ. Если интеграция нужна, переносите её на REST API или оставляйте точечный доступ вместо полного запрета.
Поставили только фильтр, но запросы всё равно грузят сервер
Фильтр xmlrpc_enabled отключает функциональность WordPress, но не всегда останавливает сам HTTP-запрос на ранней стадии. Если атака идёт массово, добавьте блокировку на уровне Nginx или Apache.
Сломали правила кэширования или WAF
Иногда после закрытия xmlrpc.php в веб-сервере остаются конфликтующие правила в плагине безопасности, CDN или WAF. Если ответ стал странным — например, вместо 403 идёт редирект или страница ошибки от прокси, проверьте цепочку правил по порядку: CDN, WAF, веб-сервер, WordPress.
Использовали код в родительской теме
Если отключение добавили в functions.php активной темы, при обновлении или смене темы правило легко потерять. Для таких задач лучше небольшой mu-plugin или собственный мини-плагин. Это надёжнее и не зависит от дизайна сайта.
Что ещё стоит проверить вместе с XML-RPC
Отключение XML-RPC не закрывает сайт полностью. Если вы уже занялись технической чисткой, проверьте и другие точки входа: форму логина, REST API для публичных маршрутов, список авторов, индексацию служебных страниц, а также наличие лишних плагинов, которые держат старые интеграции. На сайтах с повышенными требованиями к безопасности полезно дополнительно ограничить попытки входа, включить двухфакторную авторизацию и убрать неиспользуемые сервисные аккаунты.
Если нужен более широкий аудит технических дублей, служебных страниц и лишних точек доступа, в экосистеме WPShop для этого есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но саму задачу отключения XML-RPC всё равно лучше понимать и уметь проверить руками.
Если после внедрения у вас перестали работать нужные внешние сервисы, не пытайтесь «разрешить всё обратно». Сначала найдите конкретный сценарий, который сломался, и восстановите только его. В технической безопасности WordPress это почти всегда лучше, чем держать открытой старую точку входа ради одного сомнительного исключения.