Если в логах постоянно светится /xmlrpc.php, а сайт получает лишние запросы на авторизацию или pingback, одного «галочного» отключения часто недостаточно. На практике удобнее закрыть этот endpoint на уровне сервера и отдельно проверить, не завязаны ли на него внешние сервисы.
Ниже — рабочий сценарий: сначала быстро диагностируем, кто и зачем стучится в xmlrpc.php, потом отключаем его безопасным способом, а после проверяем, что админка, REST API и обычные входы продолжают работать.
Когда xmlrpc.php действительно стоит отключать
xmlrpc.php нужен для старых клиентов, некоторых мобильных приложений, внешних публикаций и pingback/trackback. Если вы этим не пользуетесь, endpoint чаще приносит лишнюю нагрузку и расширяет поверхность атаки. Но отключать его «вслепую» не стоит: иногда на него завязаны приложения для публикации или интеграции с внешними сервисами.
Что проверить до изменений
- есть ли в логах повторяющиеся POST-запросы к
/xmlrpc.php; - используются ли внешние клиенты WordPress для публикации;
- нужны ли pingback/trackback на этом сайте;
- есть ли плагин безопасности, который уже блокирует XML-RPC частично или полностью.
Диагностика: как понять, что проблема именно в xmlrpc.php
Самый простой способ — посмотреть access log веб-сервера. Если у вас Nginx, ищите строки с xmlrpc.php и большим числом запросов с одного IP. Для Apache логика та же: важны повторяющиеся обращения и статус-коды 200/403/404.
# Nginx: быстрый поиск по логам
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50
# Apache: аналогично
grep "xmlrpc.php" /var/log/apache2/access.log | tail -n 50Если доступа к серверу нет, можно временно открыть DevTools или использовать плагины логирования безопасности. Но серверные логи точнее: они покажут не только факт обращения, но и частоту.
Как отключить xmlrpc.php безопасно
Есть три нормальных варианта: блокировка на сервере, фильтр в WordPress и плагин безопасности. Для продакшена я бы начинал с сервера, а если нужен более мягкий контроль — добавлял фильтр в код темы или mu-plugin.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Серверная блокировка | Быстро, рано отсекает запросы | Нужно править конфиг | Если есть доступ к Nginx/Apache |
| Фильтр в WordPress | Просто внедрить, легко откатить | Запрос до PHP всё равно доходит | Если нет доступа к серверу |
| Плагин безопасности | Удобно для админов без кода | Зависимость от плагина | Если уже используете security-плагин |
Вариант 1. Блокировка в Nginx
Если сайт работает на Nginx, можно вернуть 444 или 403 только для xmlrpc.php. Это самый прямой способ, потому что запрос не доходит до WordPress.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
return 444;
}Если на сервере уже есть отдельный location для PHP, убедитесь, что это правило стоит выше общего обработчика. После правки выполните проверку конфигурации и перезагрузку:
nginx -t && systemctl reload nginxВариант 2. Блокировка в Apache через .htaccess
Для Apache можно закрыть файл через .htaccess. Это не так рано, как на уровне сервера, но для большинства сайтов работает нормально.
<Files "xmlrpc.php">
Require all denied
</Files>Если у вас старая версия Apache и старый синтаксис, иногда встречается Deny from all, но на актуальных установках лучше использовать Require all denied.
Вариант 3. Отключение через WordPress-фильтр
Если серверный доступ ограничен, можно отключить XML-RPC через код. Лучше не вставлять это в functions.php активной темы, а положить в mu-plugin, чтобы правило не исчезло после смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот способ корректно отключает сам механизм WordPress, но запрос всё равно сначала попадёт в PHP. Для небольшого сайта это приемлемо, для атакуемого ресурса лучше закрывать endpoint раньше.
Пошаговое решение без лишнего риска
- Проверьте логи и убедитесь, что
xmlrpc.phpвам не нужен для рабочих интеграций. - Сделайте бэкап конфигурации веб-сервера или
.htaccess. - Добавьте блокировку на уровне Nginx или Apache.
- Если серверный доступ недоступен, добавьте фильтр
xmlrpc_enabledчерез mu-plugin. - Очистите кеш, если он есть на уровне плагина, сервера или CDN.
- Проверьте ответ на прямой запрос к
/xmlrpc.php.
Как проверить, что отключение сработало
Проверка должна быть не «на глаз», а по факту ответа сервера. Самый простой тест — запросить endpoint и посмотреть код ответа.
curl -I https://example.com/xmlrpc.phpОжидаемый результат зависит от способа блокировки: при серверной защите это может быть 403, 404 или даже отсутствие ответа в случае 444 на Nginx. Если вы использовали фильтр WordPress, часто увидите 403 или сообщение о том, что XML-RPC отключён.
Дополнительно проверьте:
- вход в админку по
/wp-login.phpработает; - обычные страницы сайта открываются без ошибок;
- REST API не сломан, если он нужен вашему сайту;
- в логах больше не растёт число обращений к
xmlrpc.phpпосле очистки кеша.
Частые ошибки и как их исправить
Сломали внешнюю публикацию или мобильное приложение
Если после блокировки перестал работать сторонний клиент, значит он реально использовал XML-RPC. В этом случае либо возвращайте доступ точечно по IP, либо переводите интеграцию на другой способ.
Поставили правило не туда
На Nginx правило может не сработать, если его добавили ниже общего PHP-обработчика. На Apache частая проблема — неверный контекст в .htaccess или отключённый модуль mod_authz_core.
Проверили только браузером
Браузерный переход на /xmlrpc.php не всегда показывает реальную картину. Нужен именно HTTP-запрос, лучше через curl или по логам сервера.
Отключили XML-RPC, но атаки не прекратились
Иногда боты продолжают стучаться в endpoint, даже получая отказ. Это нормально: цель не в том, чтобы «убедить» бота, а в том, чтобы не отдавать WordPress на обработку. Если запросы очень частые, добавьте rate limit на уровне сервера или CDN.
Безопасность и производительность: что ещё имеет смысл сделать
Если вы уже трогаете защиту входа, проверьте соседние точки риска: /wp-login.php, устаревшие плагины, открытые авторские архивы и лишние REST-эндпоинты. Не стоит закрывать всё подряд, но полезно убрать то, чем сайт точно не пользуется.
Для сайтов, где админка часто атакуется, имеет смысл дополнительно включить двухфакторную авторизацию, ограничение попыток входа и базовую защиту на уровне WAF/CDN. Если нужен более широкий набор технической чистки, удобно смотреть в сторону инструментов вроде Clearfy Pro, но только как дополнение к серверным правилам, а не вместо них.
Главная идея простая: xmlrpc.php лучше отключать там, где он не нужен, и делать это так, чтобы решение было проверяемым и обратимым. Тогда вы не ломаете рабочие интеграции и не оставляете лишнюю нагрузку на PHP.