XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация через старые клиенты или отдельные интеграции. На практике задача не в том, чтобы просто заблокировать xmlrpc.php, а в том, чтобы понять, нужен ли он вообще и чем заменить его функции, если сайт уже живёт на REST API.
Если у вас нет старых интеграций, которые завязаны именно на XML-RPC, отключение обычно оправдано: это уменьшает поверхность атаки и убирает один из популярных векторов брутфорса. Но делать это лучше после проверки зависимостей, а не до неё.
Когда XML-RPC действительно мешает
Самый частый сценарий — сайт использует только админку WordPress и обычные формы, а xmlrpc.php остаётся открытым без необходимости. В логах при этом могут появляться запросы к /xmlrpc.php, а в панели безопасности — предупреждения о попытках подбора паролей через system.multicall.
Есть и обратная ситуация: XML-RPC нужен не для публикации постов, а для конкретного сервиса. Например, старый клиент для удалённого редактирования, интеграция с приложением или Jetpack в режиме, где часть функций ещё использует этот канал. В таком случае блокировать файл целиком нельзя, пока не проверены альтернативы.
Что проверить до отключения
- используется ли Jetpack и какие модули включены;
- есть ли мобильные приложения или внешние редакторы, которые публикуют записи;
- настроены ли сторонние сервисы синхронизации, которые обращаются к
xmlrpc.php; - есть ли в логах реальные обращения к XML-RPC не только от сканеров, но и от ваших систем;
- не завязан ли на XML-RPC старый плагин, который давно не обновлялся.
Диагностика: как понять, используется ли xmlrpc.php
Проверка начинается с простого запроса. Если файл доступен, сервер обычно отвечает кодом 405 на GET-запрос, но это ещё не значит, что XML-RPC нужен. Важнее посмотреть, проходят ли POST-запросы и кто их отправляет.
curl -I https://example.com/xmlrpc.phpЕсли вы хотите проверить именно поведение XML-RPC, можно отправить тестовый POST-запрос. Для живого сайта не стоит делать это часто, но один ручной тест помогает понять, отвечает ли endpoint вообще.
curl -s -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'Если в ответе есть список методов, endpoint активен. Дальше смотрите логи веб-сервера и логи безопасности: реальные интеграции обычно идут с предсказуемых IP или хотя бы с повторяющихся пользовательских агентов, а сканеры — с хаотичных адресов и частыми ошибками авторизации.
Как отключить XML-RPC: рабочие варианты
Есть три нормальных подхода: отключить через код, заблокировать на уровне веб-сервера или использовать плагин безопасности. Выбор зависит от того, нужен ли вам точечный контроль или достаточно быстрого решения.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или MU-плагине | Точный контроль, легко откатить | Нужно следить за обновлениями и местом размещения кода |
| Правило в Nginx/Apache | Блокирует запросы до WordPress | Требует доступа к серверу и аккуратной настройки |
| Плагин безопасности | Быстро включить без правок кода | Лишняя зависимость и возможные конфликты |
Вариант 1: отключение через код
Если нужен самый простой и прозрачный способ, добавьте фильтр xmlrpc_enabled. Лучше делать это в MU-плагине или в отдельном мини-плагине, а не в functions.php активной темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Такой вариант отключает XML-RPC на уровне WordPress. Если какой-то внешний сервис продолжит стучаться в xmlrpc.php, он получит отказ уже от ядра, но сам файл останется доступным для запроса. Для большинства сайтов этого достаточно, если цель — убрать функциональность, а не только скрыть endpoint.
Вариант 2: блокировка на уровне Nginx
Если у вас Nginx, можно отрезать доступ к файлу ещё до запуска PHP. Это полезно, когда нужно снизить нагрузку от массовых запросов и не отдавать обработку WordPress вообще.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache логика похожая, но правило будет другим. Если сервером управляет хостинг, не вносите изменения вслепую: сначала проверьте, как у вас подключаются дополнительные директивы, чтобы не сломать конфигурацию сайта.
Вариант 3: плагин безопасности
Если на сайте уже стоит плагин безопасности, в нём часто есть отдельная опция для XML-RPC. Это удобно, когда вы не хотите править конфиг сервера и код. Но перед включением проверьте, не делает ли плагин лишнего: некоторые решения блокируют не только XML-RPC, но и связанные с ним легитимные сценарии.
Если нужен более широкий набор защитных и SEO-настроек, иногда удобнее использовать Clearfy Pro, но только если его функции реально закрывают вашу задачу и не дублируют уже установленный стек. Ставить плагин ради одной галочки обычно невыгодно.
Пошаговое решение без лишнего риска
Ниже рабочая последовательность, которая помогает не сломать интеграции.
- Проверьте, есть ли реальные обращения к
xmlrpc.phpв логах. - Отключите XML-RPC сначала через фильтр
xmlrpc_enabled, а не через жёсткую блокировку на сервере. - Проверьте админку, публикацию записей, мобильные клиенты и внешние сервисы.
- Если всё работает, добавьте блокировку на уровне веб-сервера для дополнительной защиты.
- Оставьте заметку в документации проекта, чтобы через полгода не искать причину отвалившейся интеграции.
Такой порядок удобен тем, что вы отделяете функциональное отключение от сетевой блокировки. Если что-то сломалось, проще понять, на каком уровне возникла проблема.
Как проверить, что отключение сработало
После внедрения нужно проверить не только код ответа, но и поведение сайта. Самая частая ошибка — убедиться, что xmlrpc.php «не открывается», и забыть про реальные сценарии использования.
- откройте
/xmlrpc.phpв браузере и убедитесь, что доступ ограничен; - повторите
curl-проверку и посмотрите, изменился ли ответ; - если использовали фильтр, проверьте, не работает ли публикация через старый внешний клиент;
- посмотрите error log и access log после нескольких минут обычной нагрузки;
- проверьте, не появились ли новые ошибки в Jetpack или других подключённых сервисах.
Если вы блокировали файл через Nginx или Apache, в логах не должно быть лишней обработки PHP для этого запроса. Если отключали только фильтром, WordPress должен отвечать отказом без фатальных ошибок.
Частые ошибки и как их исправить
Отключили XML-RPC, а перестал работать Jetpack
Значит, у вас есть зависимость, о которой забыли. Верните фильтр назад, проверьте, какие функции Jetpack реально используются, и решите, можно ли заменить их REST API или встроенными возможностями WordPress.
Заблокировали xmlrpc.php в сервере, но запросы всё равно видны
Часто это означает, что правило не попало в активный server block или .htaccess, либо запросы идут через другой виртуальный хост. Проверьте, что правило применено именно к нужному домену и что конфигурация была перезагружена.
Использовали плагин, а он конфликтует с кешем или безопасностью
Такое бывает, если плагин дублирует уже существующее правило. В этом случае лучше оставить один уровень блокировки: либо код, либо сервер, либо плагин. Смешивать всё сразу без необходимости не стоит.
Скрыли проблему, но не убрали причину
Если на сайт идут массовые запросы к XML-RPC, одной блокировки мало. Проверьте WAF, rate limiting на сервере и базовую защиту авторизации. Иначе нагрузка может перейти на другие уязвимые точки.
Безопасность и производительность: что ещё имеет смысл сделать
После отключения XML-RPC полезно посмотреть на соседние настройки. Если сайт работает на обычном REST API, убедитесь, что нет лишних открытых точек входа, которые вы не используете. Также имеет смысл проверить актуальность плагинов и убрать старые интеграции, которые давно не нужны.
Если у вас большой проект, блокировка XML-RPC на уровне сервера даёт ещё и небольшой выигрыш по ресурсам: запросы от сканеров не доходят до PHP. Это не заменяет нормальный кеш и защиту от брутфорса, но помогает убрать один из постоянных шумовых источников.
Для сайтов с несколькими администраторами полезно зафиксировать в регламенте, какие внешние сервисы имеют право обращаться к WordPress и через какой интерфейс. Тогда отключение XML-RPC не станет сюрпризом при следующем обновлении или переносе сайта.