XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать сторонние приложения, удалённая публикация или интеграции с сервисами, которые всё ещё используют этот протокол. Проблема в том, что у XML-RPC нет одного универсального сценария: на одном сайте он действительно лишний, на другом — завязан на рабочий процесс редакции.
Если задача стоит именно в снижении поверхности атаки, а не в слепом удалении функциональности, сначала нужно понять, кто и как обращается к xmlrpc.php. Только после этого имеет смысл выбирать: отключать полностью, ограничивать доступ или оставить, но закрыть лишние методы.
Когда XML-RPC мешает, а когда он всё ещё нужен
На практике XML-RPC нужен реже, чем кажется. Но полностью выключать его стоит не всем. Если сайт давно живёт только в браузере, без Jetpack, без старых мобильных клиентов и без внешних публикаций, отключение обычно проходит безболезненно. Если же редакторы публикуют материалы из сторонних приложений, используют синхронизацию с сервисами или старые интеграции, сначала проверьте зависимые сценарии.
Типичные признаки, что XML-RPC можно убрать
- в логах есть регулярные обращения к
/xmlrpc.php, но они не связаны с вашими сервисами; - сайт не использует Jetpack или аналогичные решения, завязанные на XML-RPC;
- публикация и редактирование контента идут только через админку WordPress;
- нет мобильных клиентов и внешних систем, которые отправляют записи через XML-RPC.
Когда отключать опасно
- используется Jetpack и связанные функции;
- есть старые приложения для публикации записей;
- интеграция с внешним сервисом прямо требует XML-RPC;
- на сайте настроены рабочие процессы, где публикация идёт не только из wp-admin.
Диагностика проблемы: кто обращается к xmlrpc.php
Перед изменениями полезно посмотреть не только факт запросов, но и их частоту. Если серверный лог доступен, ищите обращения к xmlrpc.php и сопоставляйте IP, user-agent и время. Это помогает отличить реальный клиент от ботов, которые просто перебирают пароль через system.multicall.
Если доступа к логам нет, можно временно включить запись запросов на уровне веб-сервера или использовать плагины безопасности, которые показывают попытки обращения к XML-RPC. Но не полагайтесь только на счётчик блокировок: важно понять, не ломаете ли вы рабочую интеграцию.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если в логах видны частые POST-запросы с одного и того же адреса, это уже повод не просто отключать файл, а проверить защиту на уровне сервера или WAF. Если же запросы идут от известных сервисов, сначала фиксируйте список зависимостей.
Как отключить XML-RPC в WordPress безопасно
Есть три рабочих подхода: отключить через код, закрыть на уровне веб-сервера или ограничить доступ только для нужных сценариев. Самый предсказуемый вариант для WordPress — фильтр xmlrpc_enabled. Он не удаляет файл физически, но отключает сам функционал на уровне ядра.
Вариант 1: отключить через functions.php или mu-plugin
Лучше добавлять такой код не в тему, а в mu-plugin или отдельный мини-плагин. Тогда отключение не исчезнет после смены темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот способ подходит, если вы уверены, что XML-RPC на сайте не нужен вообще. После добавления WordPress перестанет принимать XML-RPC-запросы, а попытки обращения будут получать отказ.
Вариант 2: закрыть доступ на уровне Nginx
Если вы управляете сервером, можно отрезать доступ к xmlrpc.php ещё до WordPress. Это полезно, когда сайт регулярно атакуют боты и вы хотите снизить нагрузку на PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правила в .htaccess или конфигурации виртуального хоста. Но если сайт работает на общем хостинге, не всегда есть доступ к серверным настройкам, и тогда проще использовать фильтр WordPress.
Вариант 3: ограничить, а не выключать
Если XML-RPC нужен только для одного сервиса, иногда разумнее не отключать его полностью, а закрыть доступ по IP или через WAF. Это компромиссный вариант: меньше риска сломать интеграцию, но защита всё равно лучше, чем открытый endpoint для всех.
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
Фильтр xmlrpc_enabled | Просто внедрить, работает на уровне WordPress | Файл остаётся доступен, запросы доходят до PHP | Если нужен быстрый и безопасный способ отключения |
| Блокировка на сервере | Снимает нагрузку с PHP, режет ботов раньше | Нужен доступ к конфигу сервера | Если есть доступ к Nginx/Apache |
| Ограничение по IP/WAF | Сохраняет нужные интеграции | Требует поддержки списка адресов | Если XML-RPC нужен точечно |
Проверка результата после внедрения
После отключения не ограничивайтесь открытием главной страницы. Проверьте именно тот сценарий, который вы меняли. Откройте /xmlrpc.php в браузере: при корректной блокировке вы не должны видеть рабочий ответ метода. Если отключали через WordPress, запрос должен завершаться отказом. Если закрывали на сервере, должен сработать запрет доступа ещё до выполнения PHP.
Дальше проверьте админку, публикацию записей и все внешние сервисы, которые могли использовать XML-RPC. Если на сайте есть мобильное приложение или интеграция с редактором, сделайте тестовую публикацию. И обязательно посмотрите логи ошибок и access log: иногда отключение не ломает функциональность сразу, но вызывает повторные попытки подключения и лишнюю нагрузку.
- проверить ответ
/xmlrpc.php; - открыть админку и создать тестовую запись;
- проверить Jetpack или другие подключённые сервисы;
- посмотреть access log на повторные обращения;
- убедиться, что нет ошибок в
debug.logили журнале сервера.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это ожидаемое поведение, а не баг WordPress. Решение простое: либо возвращаете XML-RPC, либо переводите Jetpack на другой сценарий, если он вообще поддерживается в вашей конфигурации. Перед отключением всегда проверяйте зависимости.
Закрыли файл через .htaccess, но запросы всё равно идут
На Nginx .htaccess не работает. Если сайт на Nginx, правило нужно добавлять в конфигурацию сервера. Если у вас прокси, CDN или WAF, блокировка может быть только на одном уровне, а запросы продолжат доходить до origin.
Использовали плагин безопасности, но нагрузка не упала
Некоторые плагины блокируют попытки уже после того, как запрос дошёл до WordPress. Это полезно для логирования, но не всегда помогает по производительности. Если цель — убрать лишнюю нагрузку, серверная блокировка эффективнее.
Сломали интеграцию, потому что не проверили внешние клиенты
Самая частая ошибка — отключать XML-RPC без инвентаризации сервисов. Перед изменениями составьте список: кто публикует, кто синхронизирует, кто авторизуется через WordPress. Если список неполный, сначала тестируйте на staging-копии.
Что ещё можно сделать для безопасности
Отключение XML-RPC — не замена нормальной защите входа. Если на сайте идут переборы паролей, проверьте и другие точки входа: /wp-login.php, REST API, слабые пароли редакторов, отсутствие двухфакторной аутентификации. Иногда лучше закрыть проблему комплексно, чем бороться только с одним endpoint.
Если нужен более широкий набор технических чисток и отключение лишних дублей, в экосистеме WordPress часто используют Clearfy Pro: он помогает убрать часть лишнего кода и настроек, которые не нужны на конкретном сайте. Но даже с таким инструментом важно отдельно проверять, что именно вы отключаете и не затрагиваете ли рабочие сценарии.
Для сайтов с высокой нагрузкой полезно дополнительно ограничить частоту запросов к чувствительным URL на уровне сервера или CDN. Это не отменяет отключение XML-RPC, но снижает шанс, что бот будет бесконечно стучаться в один и тот же endpoint.
Если вам нужен практический критерий, решение считается удачным, когда xmlrpc.php больше не используется легитимными сервисами, а в логах исчезают массовые попытки обращения. Тогда вы убираете лишний вектор атаки без побочных эффектов для редакции и интеграций.