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