XML-RPC в WordPress часто отключают ради безопасности и снижения лишнего трафика, но делать это вслепую нельзя: на некоторых сайтах через него до сих пор работают внешние сервисы, мобильные клиенты и интеграции. Если просто закрыть endpoint, можно получить неочевидные поломки — от ошибок синхронизации до проблем с публикацией из сторонних приложений.
Ниже — рабочий сценарий: как понять, нужен ли вам XML-RPC, как отключить его точечно через код, чем это отличается от блокировки на уровне сервера и как проверить результат без догадок.
Когда XML-RPC действительно стоит отключать
Если сайт не использует старые внешние клиенты, а публикация и управление идут только через админку WordPress, XML-RPC обычно не нужен. На практике его отключают, когда:
- сайт получает много запросов к
/xmlrpc.phpиз логов; - нужно уменьшить поверхность атаки для брутфорса;
- нет интеграций, которые завязаны на XML-RPC;
- вы хотите оставить REST API для современных подключений, а старый протокол убрать.
Если у вас есть Jetpack, старые мобильные приложения, внешние сервисы автопостинга или синхронизации, сначала проверьте, используют ли они XML-RPC именно в вашей конфигурации. Не все интеграции одинаковы: часть давно перешла на REST API, часть может работать только через XML-RPC.
Диагностика: как понять, используется ли xmlrpc.php
Самый простой способ — посмотреть логи веб-сервера или логи доступа в панели хостинга. Ищите обращения к /xmlrpc.php. Если запросы идут регулярно и от одних и тех же IP, это может быть как легитимная интеграция, так и перебор паролей.
Что проверить до отключения
- есть ли в логах успешные запросы к
xmlrpc.php; - используется ли Jetpack или сторонняя публикация из внешнего клиента;
- есть ли мобильные приложения, которые подключаются к сайту;
- не завязана ли на XML-RPC синхронизация с CRM или сервисом рассылок;
- не стоит ли уже WAF или модуль безопасности, который блокирует подозрительные запросы.
Если доступа к логам нет, можно временно проверить endpoint вручную: откройте https://example.com/xmlrpc.php. Для живого XML-RPC WordPress обычно отвечает сообщением о том, что сервер принимает только POST-запросы. Это не доказательство использования, но подтверждает, что endpoint доступен.
Пошаговое решение: отключаем XML-RPC через functions.php
Для большинства сайтов достаточно отключить XML-RPC через фильтр xmlrpc_enabled. Это безопаснее, чем править ядро или удалять файл xmlrpc.php вручную.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Код можно добавить в functions.php дочерней темы или, что предпочтительнее, в небольшой mu-plugin. Второй вариант надежнее: он не зависит от темы и не исчезнет после обновления.
Вариант для mu-plugin
Создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php, и добавьте туда:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );После этого WordPress перестанет принимать XML-RPC-запросы на уровне приложения. Если нужно оставить файл доступным, но не обрабатывать запросы, этого обычно достаточно.
Если нужен более жесткий вариант
Иногда администраторы хотят не только отключить обработку, но и сразу отдавать 403 на сам файл. Это уже уровень сервера. Для Apache можно использовать правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx блокировка делается в конфигурации сайта, например:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Серверный вариант полезен, если вам нужно уменьшить нагрузку и не пускать запросы даже до WordPress. Но если вы не уверены в конфигурации хостинга, сначала используйте фильтр xmlrpc_enabled: он проще откатывается.
Сравнение подходов
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
Фильтр xmlrpc_enabled | Просто, безопасно, легко откатить | Запросы могут доходить до WordPress | Если нужен быстрый и контролируемый способ |
| mu-plugin | Не зависит от темы | Нужно создать отдельный файл | Если сайт активно обновляется и тема меняется |
| Блокировка на сервере | Жестко отсекает запросы раньше WordPress | Нужен доступ к конфигу сервера | Если важны безопасность и экономия ресурсов |
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. После внедрения выполните несколько шагов.
- Откройте
/xmlrpc.phpв браузере. Вместо стандартного ответа WordPress вы должны увидеть отказ или пустой ответ в зависимости от способа блокировки. - Проверьте логи сервера: запросы к
xmlrpc.phpдолжны либо исчезнуть, либо получать 403/405. - Если у вас есть интеграция, которая раньше работала через XML-RPC, попробуйте выполнить её тестовый сценарий и убедитесь, что она не сломалась.
- Проверьте админку и публикацию записей: отключение XML-RPC не должно влиять на обычную работу WordPress.
Если вы используете командную строку, можно быстро проверить ответ так:
curl -I https://example.com/xmlrpc.phpДля отключенного endpoint ожидаемым результатом будет не стандартный XML-RPC-ответ WordPress, а отказ в доступе или иной код, который вы задали на сервере.
Частые ошибки и как их исправить
Сломали интеграцию, которая использовала XML-RPC
Это самая частая проблема. Если после отключения перестала работать публикация из внешнего сервиса, сначала проверьте, можно ли перевести его на REST API. Если нет — не блокируйте XML-RPC глобально, а ограничьте доступ по IP или оставьте его включенным только для нужного сервиса через правила сервера.
Отключили не там, где нужно
Если код добавлен в активную тему, а потом тема обновилась или была заменена, защита исчезнет. Для постоянного правила лучше использовать mu-plugin.
Путают отключение XML-RPC с отключением REST API
Это разные механизмы. XML-RPC — старый протокол, REST API — современный интерфейс WordPress. Если вам нужен мобильный клиент или интеграция с приложением, не рубите REST API без необходимости.
Блокируют файл, но не проверяют логи
Если просто закрыть xmlrpc.php, но не посмотреть статистику запросов, можно не заметить, что атака продолжается уже на другие точки входа. После отключения полезно проверить и общую картину по логам.
Практические советы по безопасности и производительности
Если цель — защита от брутфорса, отключение XML-RPC стоит сочетать с нормальной политикой паролей, ограничением попыток входа и актуальными обновлениями ядра, тем и плагинов. Само по себе закрытие одного endpoint не делает сайт защищенным.
Если сайт получает много мусорных запросов, серверная блокировка обычно эффективнее: она экономит PHP-процессы и уменьшает нагрузку. Но вносить такие правила лучше после теста на staging-копии, особенно если хостинг использует нестандартную схему маршрутизации.
Для сайтов, где часто меняются темы и плагины, удобнее держать технические правки в mu-plugins или в отдельном мини-плагине. Так вы не потеряете настройку при обновлении дизайна.
Что делать, если XML-RPC нужен частично
Иногда полностью отключать протокол нельзя. В таком случае разумнее ограничить доступ точечно: оставить его только для конкретного IP, VPN или внутреннего сервиса. Это уже задача уровня веб-сервера или WAF, а не WordPress-кода.
Если у вас есть сомнения, сначала включите мониторинг запросов к xmlrpc.php на несколько дней, затем отключайте endpoint и повторно проверяйте логи. Такой подход лучше, чем удалять доступ без анализа последствий.