XML-RPC в WordPress нужен не всем. Если вы не используете старые мобильные клиенты, внешние сервисы публикации или интеграции, которые до сих пор ходят через xmlrpc.php, этот endpoint чаще становится лишней точкой атаки, чем полезной функцией. На практике его отключают ради снижения шума в логах, уменьшения поверхности атаки и защиты от перебора паролей через методы вроде system.multicall.
Ниже — не абстрактная теория, а рабочий сценарий: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его без поломки админки и интеграций, и как проверить результат после внедрения.
Когда XML-RPC действительно стоит отключать
Не надо выключать его «на всякий случай», если у вас есть зависимые сервисы. Сначала проверьте, используется ли endpoint вообще. Типичные признаки, что XML-RPC можно убрать:
- в логах веб-сервера регулярно видны запросы к
/xmlrpc.php; - вы не публикуете записи через внешние клиенты и не синхронизируете контент через старые интеграции;
- мобильное приложение WordPress не используется;
- в панели безопасности уже есть отдельная защита от брутфорса, но endpoint всё равно открыт.
Если сайт подключён к сервисам, которые работают через XML-RPC, отключение может сломать публикацию, пингбэки или удалённое управление. Поэтому сначала диагностика, потом изменение конфигурации.
Диагностика: как понять, что XML-RPC активен и кто его дергает
Самый простой способ — открыть https://ваш-домен/xmlrpc.php в браузере или через curl. Если endpoint доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не ошибка, а признак того, что файл жив и отвечает.
curl -I https://example.com/xmlrpc.phpДля более точной проверки посмотрите access-логи. Если у вас Nginx или Apache, ищите частые обращения к xmlrpc.php с разных IP и большим количеством попыток авторизации. Особенно подозрительны пачки POST-запросов с коротким интервалом.
Если есть доступ к WP-CLI, можно быстро проверить, не завязаны ли на XML-RPC сторонние сценарии, но прямой команды для «проверки использования XML-RPC» в WordPress нет. Здесь важнее анализ логов и понимание, какие сервисы подключены к сайту.
Что проверить перед отключением
- используете ли вы Jetpack или похожие сервисы, которым может понадобиться XML-RPC;
- есть ли внешние публикации из редакторов и мобильных приложений;
- не настроены ли старые интеграции с CRM или автопостингом;
- не завязаны ли на XML-RPC мониторинг или синхронизация контента.
Как отключить XML-RPC: три рабочих подхода
Есть несколько способов закрыть endpoint. Для большинства сайтов достаточно кода в теме или, лучше, в небольшом mu-plugin. Если у вас уже стоит плагин безопасности, проверьте, не делает ли он это сам, чтобы не дублировать правила.
| Способ | Когда подходит | Минус |
|---|---|---|
Код через xmlrpc_enabled | Нужен точечный и контролируемый запрет | Не всегда блокирует сам файл на уровне веб-сервера |
| Правило в Nginx/Apache | Нужно отрезать endpoint до WordPress | Надо править конфиг сервера |
| Плагин безопасности | Нужна настройка без кода | Лишняя зависимость и риск конфликтов |
Вариант 1: отключить через фильтр WordPress
Это самый аккуратный способ, если вам нужен именно запрет на уровне WordPress. Добавьте код в functions.php дочерней темы или, что лучше, в mu-plugin.
<?php
add_filter('xmlrpc_enabled', '__return_false');Этот фильтр отключает XML-RPC внутри WordPress. Для большинства сценариев этого достаточно, но если сервер продолжает отдавать файл напрямую, лучше дополнительно закрыть его на уровне веб-сервера.
Вариант 2: закрыть xmlrpc.php на уровне Nginx
Если сайт работает на Nginx, можно отдать 403 ещё до запуска PHP. Это снижает нагрузку и убирает лишние обращения к WordPress.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После правки конфигурации проверьте синтаксис и перезагрузите сервер. Для Nginx это обычно выглядит так:
nginx -t
systemctl reload nginxВариант 3: закрыть через Apache
Если сайт на Apache, можно использовать правило в .htaccess или конфиге виртуального хоста. Для .htaccess подойдёт такой вариант:
<Files xmlrpc.php>
Require all denied
</Files>Этот способ тоже блокирует доступ до WordPress. Если у вас уже есть правила безопасности в .htaccess, проверьте, чтобы они не конфликтовали между собой.
Пошаговое решение без лишнего риска
Если нужен предсказуемый результат, действуйте по такой схеме:
- Проверьте логи и список интеграций, которые могут использовать XML-RPC.
- Сделайте резервную копию конфигурации сервера и файлов сайта.
- Отключите XML-RPC через фильтр
xmlrpc_enabledили правило веб-сервера. - Очистите кэш, если на сайте стоит кэширование страниц или прокси.
- Проверьте ответ
xmlrpc.phpи логи после изменения.
Если вы не уверены, начните с фильтра WordPress. Это проще откатить, чем правку серверного конфига. Но для сайтов с высоким трафиком и постоянными атаками лучше закрывать endpoint на уровне веб-сервера.
Как проверить, что отключение сработало
Проверка должна быть не «страница не открывается в браузере», а именно техническая. Смотрите на код ответа и поведение сервера.
curl -I https://example.com/xmlrpc.phpОжидаемый результат после блокировки — 403 Forbidden или другой явный запрет доступа. Если вы используете только фильтр WordPress, ответ может зависеть от конфигурации сервера и кэша, поэтому проверяйте и HTTP-статус, и содержимое ответа.
Дополнительно проверьте, не сломались ли связанные функции:
- публикация из внешних клиентов;
- синхронизация с сервисами автоматизации;
- работа мобильного приложения WordPress;
- интеграции, которые используют старый XML-RPC API.
Если после отключения в логах всё ещё идут обращения к xmlrpc.php, значит блокировка неполная: либо правило не применилось, либо запросы доходят до другого уровня инфраструктуры.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про кэш
Если на сайте есть серверный кэш, CDN или плагин кэширования, старый ответ может какое-то время оставаться доступным. После изменений очистите кэш на всех уровнях: плагин, сервер, CDN.
Поставили правило в теме и потеряли его после обновления
Код в родительской теме — плохая идея. После обновления он исчезнет. Используйте дочернюю тему или mu-plugin, если правило должно жить долго.
Закрыли endpoint, но не проверили зависимые сервисы
Это самая дорогая ошибка. Если сайт перестал публиковать контент в сторонний сервис, причина часто неочевидна. Перед блокировкой составьте список интеграций, а после — протестируйте их вручную.
Ограничились только плагином безопасности
Плагин может скрыть endpoint на уровне WordPress, но не всегда отсекает запросы до PHP. Для сайтов под нагрузкой лучше закрывать xmlrpc.php на уровне веб-сервера, а не только в админке плагина.
Практические советы по безопасности и производительности
Если цель — не просто убрать одну точку входа, а снизить шум и нагрузку, смотрите шире. XML-RPC часто фигурирует в массовых атаках на слабые пароли. Поэтому вместе с отключением endpoint имеет смысл:
- включить двухфакторную аутентификацию для админов;
- ограничить попытки входа;
- проверить права на
wp-adminиwp-login.php; - убрать лишние плагины, которые добавляют внешние точки входа;
- следить за логами 403 и 404, чтобы видеть аномальную активность.
Если вам нужен набор инструментов для технической чистки сайта, в экосистеме WPShop есть Clearfy Pro: он помогает закрывать дубли и лишние технические сущности, а также упрощает часть базовой оптимизации. Но даже с таким плагином полезно понимать, что именно вы отключаете и почему.
Что делать, если XML-RPC всё-таки нужен
Иногда endpoint нельзя убрать полностью. Тогда не отключайте его вслепую. Лучше ограничьте доступ на уровне веб-сервера по IP, если интеграция работает с фиксированными адресами, и отдельно проверьте, какие методы реально используются. В ряде случаев достаточно не блокировать всё подряд, а закрыть только лишние сценарии и усилить аутентификацию.
Главный ориентир простой: если XML-RPC не даёт сайту ощутимой пользы, но создаёт вход для перебора и лишние запросы, его лучше отключить. Если польза есть — ограничьте доступ и проверьте интеграции, а не ломайте их ради формальной безопасности.