XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильные клиенты, внешние публикации и некоторые сервисы автопостинга. Проблема не в самом файле xmlrpc.php, а в том, что его обычно рубят без проверки зависимостей. Ниже — рабочий сценарий: как понять, нужен ли вам XML-RPC, как отключить его безопасно и чем проверить результат.
Когда XML-RPC действительно стоит отключать
Если сайт редактируется только через админку WordPress, а внешние сервисы не публикуют записи и не управляют сайтом через старый API, XML-RPC чаще всего не нужен. Его отключают ради уменьшения поверхности атаки и чтобы убрать лишний публичный endpoint, который регулярно сканируют боты.
Но есть нюанс: некоторые интеграции до сих пор используют XML-RPC. Это могут быть старые мобильные приложения, внешние редакторы, сервисы массовой публикации и отдельные плагины синхронизации. Поэтому сначала нужно проверить, кто вообще обращается к xmlrpc.php.
Как понять, используется ли XML-RPC сейчас
Самый практичный способ — посмотреть логи веб-сервера. Если у вас есть доступ к access.log, ищите запросы к /xmlrpc.php. В идеале вы увидите либо редкие обращения, либо только ботов.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если логов нет, проверьте список плагинов и внешних сервисов, которые публикуют контент или синхронизируют данные. Особенно внимательно смотрите на старые интеграции, которые были подключены много лет назад и давно забыты.
- мобильные клиенты WordPress старых версий;
- сервисы автопостинга и кросспостинга;
- внешние редакторы и CMS-агенты;
- плагины резервного копирования или синхронизации, если они используют XML-RPC для удалённых операций.
Диагностика: что именно ломается после отключения
Типичная ошибка — отключить XML-RPC и заметить проблему только после жалобы редактора или падения публикации из внешнего сервиса. Поэтому перед изменениями проверьте несколько сценариев вручную.
- открывается ли
https://example.com/xmlrpc.phpи что возвращает сервер; - публикуются ли записи из внешнего сервиса, если он у вас есть;
- работает ли приложение WordPress на телефоне, если вы им пользуетесь;
- не завязаны ли на XML-RPC сторонние интеграции через старые API-методы.
Если при обращении к xmlrpc.php вы видите ответ вроде XML-RPC server accepts POST requests only., это нормально: endpoint доступен. Если после отключения он должен стать недоступным, но продолжает отвечать, значит правило не применилось или его перебивает другой слой — плагин, nginx-конфиг, кэш или WAF.
Пошаговое отключение XML-RPC
Есть три нормальных варианта: через плагин, через код и на уровне веб-сервера. Для большинства сайтов достаточно кода или плагина. На сервере имеет смысл закрывать endpoint дополнительно, если вы уверены, что он нигде не нужен.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин | Быстро, без правки темы | Лишняя зависимость, иногда избыточный функционал |
| Код | Прозрачно, легко контролировать | Нужно аккуратно разместить в mu-plugin или теме |
| Сервер | Режет запросы раньше WordPress | Нужен доступ к конфигу nginx/apache |
Вариант 1: отключить через код
Если нужен точечный и предсказуемый способ, добавьте фильтр в mu-plugin или в небольшой плагин. Так правило не потеряется при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает сам XML-RPC на уровне WordPress. Запросы к xmlrpc.php будут получать отказ уже внутри ядра.
Вариант 2: закрыть доступ на уровне nginx
Если сайт под nginx и XML-RPC точно не нужен, можно отрезать доступ до PHP. Это полезно, когда бот-сканирование создаёт лишнюю нагрузку.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации не забудьте проверить синтаксис и перезагрузить nginx. Если у вас Apache, логика будет другой, но смысл тот же: блокировать запросы раньше WordPress.
Вариант 3: использовать плагин безопасности
Если вы уже используете плагин для базовой защиты, проверьте, умеет ли он отключать XML-RPC без побочных эффектов. Это удобно, когда не хочется размазывать настройки по коду и серверу. Но не ставьте отдельный плагин только ради одной галочки, если задача решается одной строкой кода.
Как проверить, что отключение сработало
Проверка должна быть не «страница открылась», а именно «endpoint больше не принимает XML-RPC-запросы». Самый простой тест — обратиться к xmlrpc.php напрямую и посмотреть ответ.
curl -I https://example.com/xmlrpc.phpЕсли вы отключали через WordPress-фильтр, при POST-запросе endpoint должен перестать выполнять XML-RPC-методы. Для ручной проверки можно отправить тестовый POST с любым XML-RPC payload через curl или Postman и убедиться, что ответ не похож на рабочий XML-RPC-метод.
Дополнительно проверьте:
- нет ли новых ошибок в логах PHP и веб-сервера;
- не перестали ли публиковаться записи из внешнего сервиса;
- не появились ли 403/404 на других URL из-за слишком широкого правила в конфиге;
- не кешируется ли старый ответ CDN или reverse proxy.
Частые ошибки и как их исправить
Отключили XML-RPC, но он всё ещё отвечает
Чаще всего правило применили не там. Например, добавили код в тему, а потом сменили тему или обновили её. Или закрыли endpoint в nginx, но запросы идут через другой серверный слой. Проверьте, где именно должен срабатывать запрет: WordPress, веб-сервер, WAF, CDN.
Сломалась внешняя публикация
Значит, интеграция действительно использовала XML-RPC. В этом случае не стоит «чинить» отключение. Лучше либо оставить XML-RPC включённым и ограничить доступ по IP, либо перевести интеграцию на REST API, если сервис это поддерживает.
Поставили плагин и получили лишнюю нагрузку
Иногда плагин безопасности делает больше, чем нужно: добавляет проверки, сканирование и дополнительные правила. Если задача только в отключении XML-RPC, код в mu-plugin обычно проще и легче для поддержки.
Закрыли endpoint слишком агрессивно
Правило вида deny all на весь каталог или неверный location-блок может задеть не только XML-RPC. Всегда проверяйте конфиг на тестовом запросе и не копируйте фрагменты без понимания, куда они вставляются.
Что делать, если XML-RPC нужен частично
Иногда полностью отключать endpoint нельзя, но и оставлять его открытым для всех не хочется. Тогда лучше не искать «магическую» настройку, а ограничить доступ по факту использования. На практике это означает:
- оставить XML-RPC включённым только для конкретного сервиса;
- ограничить доступ по IP на уровне сервера или WAF;
- перевести всё, что можно, на REST API;
- убрать старые интеграции, которые уже не используются.
Если вы ведёте сайт как технический проект, полезно один раз зафиксировать, какие внешние сервисы имеют право публиковать контент. Тогда отключение XML-RPC не станет сюрпризом в будущем.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не делает сайт «защищённым», но убирает один лишний публичный вход. Это разумная часть базовой гигиены, особенно если сайт давно живёт и оброс плагинами. Дополнительно стоит проверить:
- не открыт ли доступ к
/wp-login.phpбез ограничений; - не используются ли слабые пароли и одинаковые учётки;
- не висит ли на сайте старый плагин, который давно не обновлялся;
- не создаёт ли бот-трафик лишнюю нагрузку на PHP и базу.
Если вам нужен более широкий набор технических чисток — отключение дублей, лишних мета-тегов, мусорных эмодзи и других мелких вещей — такие задачи обычно удобнее решать отдельным набором настроек, а не десятком разрозненных плагинов. Но для XML-RPC лучше держаться простого и проверяемого решения: либо код, либо серверное правило, либо понятный плагин без лишней магии.
После внедрения ещё раз проверьте логи через день-два. Если на xmlrpc.php продолжают сыпаться запросы, значит ботам всё ещё есть что сканировать, а правило стоит перенести ближе к веб-серверу или WAF.