XML-RPC в WordPress часто держат включённым «на всякий случай», а потом удивляются лишним запросам, попыткам брутфорса и странным обращениям к /xmlrpc.php. Если вы не пользуетесь мобильным приложением WordPress, внешними сервисами публикации или старыми интеграциями, этот интерфейс обычно только расширяет поверхность атаки.
Но отключать его вслепую не стоит: у части сайтов через XML-RPC до сих пор работают Jetpack, удалённая публикация, некоторые старые клиенты и сервисы мониторинга. Ниже — как понять, нужен ли он вам, чем лучше отключать и как проверить, что ничего не отвалилось.
Когда XML-RPC действительно можно отключить
Сначала проверьте не «нравится ли вам файл xmlrpc.php», а есть ли у сайта реальные зависимости. Если сайт редактируется только через админку, а интеграции идут через REST API или прямые вебхуки, XML-RPC обычно не нужен.
Сценарии, где отключение обычно безопасно
- контент публикуется только из панели WordPress;
- нет мобильного приложения WordPress;
- нет Jetpack или он не использует XML-RPC для нужных функций;
- нет внешних сервисов, которые подключаются к сайту по старому протоколу;
- нет удалённой публикации из сторонних редакторов.
Что может сломаться
Если отключить XML-RPC без проверки, могут перестать работать удалённая публикация, pingback/trackback-логика и отдельные плагины, которые до сих пор используют этот канал. На современных проектах это редкость, но на старых сайтах такие зависимости встречаются чаще, чем кажется.
Диагностика: есть ли обращения к xmlrpc.php
Перед изменениями полезно посмотреть, кто вообще стучится в этот файл. Если запросы идут только от ботов, это аргумент в пользу отключения. Если видите легитимные обращения от ваших сервисов — сначала разберитесь с ними.
Что проверить в логах
- частоту запросов к
/xmlrpc.php; - IP-адреса и user-agent;
- коды ответа — особенно массовые
200,401,403и404; - есть ли совпадение по времени с жалобами на вход в админку или нагрузку.
Если доступа к логам нет, можно хотя бы открыть https://ваш-домен/xmlrpc.php в браузере. Нормальный ответ WordPress обычно выглядит как сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не проверка безопасности, но быстрый индикатор того, что файл доступен.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, где вам удобнее контролировать поведение сайта. Для большинства проектов достаточно одного из трёх способов: через плагин, через код в теме или через серверную конфигурацию. Если у вас несколько сайтов, лучше стандартизировать подход на уровне сервера или mu-plugin.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин | Нужна быстрая настройка без кода | Просто включить и проверить | Ещё один плагин в стеке |
Код в functions.php или mu-plugin | Есть доступ к теме или must-use плагинам | Контроль в коде, без лишних интерфейсов | Нужно не забыть при смене темы |
| Серверная блокировка | Есть доступ к Nginx/Apache | Отсекает запросы раньше WordPress | Нужны права на конфиг сервера |
Вариант 1: отключить через код
Самый понятный способ — вернуть false через фильтр xmlrpc_enabled. Это не ломает ядро и легко откатывается.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если хотите оставить XML-RPC включённым только для отдельных сценариев, этот вариант не подойдёт: фильтр отключает его целиком. Для точечной фильтрации обычно уже нужен более сложный серверный или плагинный подход.
Вариант 2: закрыть файл на уровне сервера
Если сайт работает на Apache, можно запретить доступ к xmlrpc.php через .htaccess. На Nginx правило добавляют в конфиг виртуального хоста. Это полезно, когда вы хотите отсечь запросы ещё до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика будет другой, но смысл тот же: запрос к файлу должен завершаться на уровне веб-сервера. Если у вас общий хостинг и доступа к конфигу нет, используйте кодовый вариант выше.
Вариант 3: плагин для точечного контроля
Если вам нужно быстро закрыть XML-RPC без правок кода, подойдёт плагин безопасности или оптимизации, который умеет отключать этот интерфейс. Здесь важен не бренд, а проверяемая функция: в настройках должна быть именно опция отключения XML-RPC, а не абстрактная «защита сайта».
На проектах, где уже стоит набор для технической чистки и SEO, иногда удобнее использовать один инструмент вместо нескольких. Например, Clearfy Pro умеет закрывать часть служебных сущностей и упрощает базовую гигиену сайта; если вы уже используете такой плагин, проверьте, нет ли там отдельной настройки для XML-RPC: https://wpshop.ru/plugins/clearfy.
Пошаговое решение без лишнего риска
- Проверьте, есть ли у сайта реальные зависимости от XML-RPC.
- Сделайте резервную копию файлов и базы, если меняете серверный конфиг или код темы.
- Выберите один способ отключения, а не несколько сразу.
- Внесите изменение и очистите кеш, если он есть на сайте, у CDN или на сервере.
- Проверьте ответ
/xmlrpc.phpи работу внешних интеграций.
Если вы правите functions.php, лучше вынести код в маленький mu-plugin. Тогда отключение не исчезнет после смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Как проверить, что решение сработало
Проверка должна быть не «страница вроде не открывается», а конкретный ответ сервера и отсутствие побочных эффектов.
- Откройте
/xmlrpc.phpв браузере: если вы закрывали файл на уровне сервера, должен быть403или аналогичный отказ. - Если отключали через фильтр, проверьте, что WordPress больше не принимает XML-RPC-запросы.
- Зайдите в сервисы, которые могли использовать XML-RPC: мобильное приложение, Jetpack, старые клиенты публикации.
- Посмотрите логи веб-сервера: запросы к
xmlrpc.phpне должны проходить в PHP, если вы блокировали их на сервере.
Если у вас включён кеш страниц, очистите его перед проверкой. Иначе можно увидеть старый ответ и сделать ложный вывод.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про Jetpack
Часть функций Jetpack исторически завязана на XML-RPC. Если после отключения пропали синхронизация или удалённые действия, проверьте, действительно ли этот плагин нужен в текущей конфигурации, и какие именно модули он использует.
Закрыли файл в .htaccess, но сайт на Nginx
Правило из Apache на Nginx не сработает. В этом случае нужно править конфиг Nginx или использовать фильтр WordPress. Не смешивайте подходы без понимания, где именно обрабатывается запрос.
Поставили два решения сразу
Иногда сначала добавляют фильтр в код, потом ещё и блокируют файл на сервере, а потом не могут понять, почему интеграция не работает. Для диагностики лучше оставить один способ и проверить его изолированно.
Правят тему вместо mu-plugin
Если код лежит в functions.php, он исчезнет при обновлении или смене темы. Для системных ограничений безопаснее использовать mu-plugin или серверную конфигурацию.
Безопасность и производительность: что меняется на практике
Отключение XML-RPC не делает сайт «защищённым вообще», но убирает один из популярных векторов перебора и лишние обращения к серверу. На нагруженных сайтах это особенно заметно, если ботнет регулярно долбит xmlrpc.php множеством POST-запросов.
Если у вас уже настроены кеш, ограничение попыток входа и нормальная политика паролей, отключение XML-RPC хорошо ложится в общую гигиену. Но не заменяет обновления ядра, тем и плагинов, а также контроль прав доступа в админке.
Для сайтов, где важна чистая техническая конфигурация, полезно держать рядом и другие меры: убрать лишние служебные страницы из индексации, отключить ненужные эндпоинты, проверить REST API и сократить число активных плагинов. Это уже не про один файл, а про общую поверхность атаки и поддержку сайта в рабочем состоянии.
Когда XML-RPC лучше не отключать
Если вы точно знаете, что через него работает мобильная публикация, внешний редактор или старый корпоративный сервис, не ломайте это ради абстрактной «безопасности». В таких случаях сначала ищут способ ограничить доступ по IP, перенести интеграцию на REST API или заменить сам сервис.
Практический критерий простой: если вы не можете назвать ни одного легитимного клиента XML-RPC на своём сайте, скорее всего, он вам не нужен. Если можете — сначала проверьте, можно ли заменить этот канал, и только потом отключайте.