XML-RPC в WordPress часто отключают по одной причине: на сайт летят лишние запросы, а в логах видно постоянные обращения к /xmlrpc.php. Но у этого файла есть и легитимные сценарии — мобильное приложение WordPress, внешние публикации, некоторые старые интеграции. Поэтому правильный подход здесь не «вырубить всё подряд», а сначала понять, кто именно использует XML-RPC, а потом закрыть только лишнее.
Когда XML-RPC действительно стоит отключать
Если сайт не использует внешнюю публикацию, старые десктопные клиенты и мобильное приложение WordPress, то XML-RPC чаще всего только создаёт поверхность атаки. На практике это проявляется так: в логах много POST-запросов к xmlrpc.php, иногда с попытками перебора логина и пароля, а иногда — с большим количеством вызовов system.multicall. Это не всегда взлом, но это лишняя нагрузка и шум.
Если же редакторы публикуют материалы через приложение WordPress, подключён Jetpack или есть сторонний сервис, который до сих пор работает через XML-RPC, отключение нужно делать точечно и с проверкой. Иначе можно получить неочевидную поломку: публикации не уходят, синхронизация не работает, а ошибка видна только в интерфейсе внешнего сервиса.
Диагностика: кто обращается к xmlrpc.php
Перед изменениями посмотрите, есть ли реальные обращения к файлу и откуда они идут. Самый простой вариант — логи веб-сервера. Если доступа к ним нет, можно временно поставить правило на уровне сервера или использовать плагин безопасности, который показывает блокировки и запросы.
Что искать в логах
- частые POST-запросы к
/xmlrpc.php; - повторяющиеся попытки авторизации с разных IP;
- вызовы
system.multicall; - ошибки 200/403/404 на один и тот же путь;
- запросы от известных интеграций, если они у вас действительно используются.
Если в логах видно только мусорный трафик, отключение обычно безопасно. Если есть запросы от мобильного приложения WordPress или внешнего сервиса, сначала проверьте, можно ли заменить интеграцию на REST API или другой способ подключения.
Способы отключения: что выбрать
Есть три рабочих подхода: через код, через сервер и через плагин. Для продакшена я обычно выбираю код или серверное правило, потому что это прозрачно и не зависит от состояния админки. Плагин удобен, если нужен быстрый откат без правок конфигурации.
| Способ | Плюсы | Минусы |
|---|---|---|
Код в functions.php или mu-plugin | Просто откатить, не требует доступа к серверу | Если тема сменится, правило может потеряться |
| Правило на сервере | Блокирует запрос раньше WordPress, меньше нагрузки | Нужен доступ к конфигу Nginx/Apache |
| Плагин безопасности | Быстро включить, удобно для теста | Лишняя зависимость, иногда больше нагрузки |
Пошаговое решение через код
Если задача — отключить XML-RPC полностью, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так правило не потеряется при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам механизм XML-RPC на уровне WordPress. Запросы на xmlrpc.php могут продолжать приходить, но WordPress будет отвечать отказом.
Если нужно не просто отключить функциональность, а ещё и убрать доступ к файлу на уровне WordPress, можно добавить отдельную проверку:
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
}
} );На практике первый вариант обычно достаточно. Второй полезен, если вы хотите явно вернуть 403 и не оставлять двусмысленных ответов.
Как закрыть xmlrpc.php на уровне сервера
Если у вас много мусорных запросов и вы хотите отсечь их до загрузки WordPress, блокируйте xmlrpc.php в конфигурации веб-сервера. Это снижает лишнюю нагрузку и уменьшает число попыток перебора.
Nginx
location = /xmlrpc.php {
return 403;
}Такой блок лучше добавлять в конфигурацию сайта, а не в общий шаблон, если у вас есть исключения для отдельных проектов.
Apache
<Files xmlrpc.php>
Require all denied
</Files>После изменения конфигурации не забудьте проверить синтаксис и перезагрузить сервис. Если сайт работает через прокси или CDN, убедитесь, что правило не конфликтует с их кэшем и правилами безопасности.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере и отправьте тестовый POST-запрос. Если XML-RPC отключён корректно, вы увидите отказ в доступе или сообщение о недоступности метода, а не обычный рабочий ответ WordPress.
Для быстрой проверки можно использовать curl:
curl -i https://example.com/xmlrpc.phpЕсли вы блокировали файл на уровне сервера, ожидайте 403 Forbidden. Если отключали только через фильтр WordPress, ответ может отличаться в зависимости от конфигурации, но XML-RPC методы работать не должны.
Дополнительно проверьте:
- мобильное приложение WordPress не публикует записи;
- внешний сервис, если он был подключён, не теряет связь;
- в логах больше нет успешных обращений к XML-RPC;
- админка и REST API продолжают работать как раньше.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестала работать публикация из внешнего сервиса
Значит, сервис действительно использовал XML-RPC. В этом случае не нужно возвращать всё назад без разбора. Проверьте, есть ли у сервиса работа через REST API или OAuth, и только потом принимайте решение. Если замены нет, оставьте XML-RPC включённым, но ограничьте доступ по IP или паролю приложения, если это возможно.
Поставили правило в теме, а после обновления оно исчезло
Это типичная ошибка. Для технических правил лучше использовать mu-plugin или отдельный мини-плагин. Тогда отключение не зависит от темы и не потеряется при редактировании шаблона.
Закрыли xmlrpc.php в .htaccess, но запросы всё равно идут
Проверьте, не работает ли сайт через Nginx перед Apache. В такой схеме .htaccess может вообще не участвовать в обработке запроса. Тогда правило нужно перенести в конфигурацию Nginx или на уровень панели управления хостингом.
Сломали интеграцию, но не поняли какую
Перед отключением полезно на несколько дней собрать логи и посмотреть, кто обращается к файлу. Если трафик идёт только от неизвестных IP и ботов, отключение безопасно. Если есть стабильный источник запросов из вашей инфраструктуры, сначала выясните назначение этого сервиса.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC само по себе не заменяет базовую защиту. Если сайт регулярно атакуют, проверьте ещё несколько вещей: сложные пароли, ограничение попыток входа, актуальные версии ядра и плагинов, а также наличие WAF на уровне хостинга или CDN. Для сайтов с высокой нагрузкой полезно отдельно посмотреть, не создаёт ли лишний трафик не только xmlrpc.php, но и /wp-login.php.
Если вам нужен более широкий набор мер по чистке сайта и снижению технического шума, имеет смысл смотреть не только на XML-RPC, но и на дубли, лишние мета-теги, эмодзи, embeds и другие мелкие источники нагрузки. В таких задачах иногда удобнее использовать набор точечных настроек, а не ставить тяжёлый универсальный плагин. Например, у Clearfy Pro есть инструменты для технической чистки WordPress: https://wpshop.ru/plugins/clearfy.
Короткий чек-лист перед выкладкой на прод
- Проверили, используется ли XML-RPC внешними сервисами.
- Выбрали способ отключения: код, сервер или плагин.
- Добавили правило в mu-plugin или конфиг сервера, а не в случайный файл темы.
- Проверили ответ
/xmlrpc.phpчерез браузер иcurl. - Убедились, что публикация, синхронизация и мобильные сценарии не сломались.
- Посмотрели логи после изменения и убедились, что лишние запросы больше не проходят.
Если задача только в том, чтобы убрать шум и снизить риск перебора, отключение XML-RPC обычно решается быстро. Но если на сайте есть старые интеграции, сначала проверьте зависимые сценарии, а уже потом закрывайте доступ окончательно.