XML-RPC в WordPress часто отключают по одной причине: через него удобно стучатся боты и перебирают учётные данные. Но у этой настройки есть обратная сторона — через XML-RPC до сих пор работают некоторые внешние приложения, мобильные клиенты и старые интеграции. Поэтому задача не в том, чтобы «просто выключить», а в том, чтобы сначала понять, кто именно его использует, и только потом резать доступ.
Если у сайта нет внешних клиентов, отключение обычно проходит безболезненно. Если же WordPress связан с мобильным приложением, сторонним сервисом публикации или старым плагином синхронизации, можно получить неочевидные сбои: от ошибок авторизации до исчезновения удалённой публикации. Ниже — рабочая схема проверки и отключения без гадания.
Когда XML-RPC действительно можно отключать
Сначала стоит отделить реальные зависимости от привычки «оставить на всякий случай». XML-RPC нужен не всем. На большинстве сайтов его используют только по инерции, а весь функционал давно переехал в REST API или вообще не нужен.
Сценарии, где отключение обычно безопасно
- вы публикуете контент только из админки WordPress;
- нет мобильного приложения WordPress;
- нет внешних сервисов, которые отправляют записи через XML-RPC;
- не используется Jetpack в режимах, где ему нужен XML-RPC для старых сценариев;
- нет старых интеграций с приложениями для автопостинга.
Сценарии, где нужно проверить зависимости
- сайт связан с мобильным редактором или приложением для публикации;
- есть синхронизация с внешней CRM или сервисом автопостинга;
- используется старый плагин, который давно не обновлялся;
- на сайте есть удалённая публикация через сторонний софт, а не через REST API.
Диагностика: как понять, используется ли XML-RPC сейчас
Самый надёжный способ — посмотреть логи и протестировать endpoint напрямую. Не стоит ориентироваться только на список плагинов: зависимость может быть вне WordPress, например в мобильном приложении редактора или в внешнем сервисе.
Проверка ответа endpoint
Откройте в браузере или через curl адрес /xmlrpc.php. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC server accepts POST requests only. Это не доказывает, что он нужен, но подтверждает, что endpoint открыт.
curl -I https://example.com/xmlrpc.phpЕсли сервер отдаёт 405 или 403, это уже признак того, что доступ ограничен на уровне сервера, плагина или правил безопасности. Если приходит обычный ответ WordPress, endpoint доступен извне.
Что искать в логах
Если у вас есть доступ к access log веб-сервера, проверьте обращения к xmlrpc.php. Важен не только факт запросов, но и их тип: массовые POST-запросы с ошибками авторизации часто указывают на брутфорс, а редкие успешные вызовы — на реальную интеграцию.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если логов нет, можно временно включить их на уровне хостинга или использовать плагин безопасности, который показывает попытки входа и обращения к чувствительным endpoint'ам. Но для принятия решения достаточно и серверных логов.
Как отключить XML-RPC: три рабочих подхода
Универсального варианта нет. На практике выбирают один из трёх: плагин, код в теме или блокировка на уровне сервера. У каждого способа свои плюсы и компромиссы.
| Способ | Когда подходит | Минус |
|---|---|---|
| Плагин безопасности | Нужен быстрый и обратимый вариант | Лишняя зависимость и возможные конфликты |
Код в functions.php или mu-plugin | Нужен точечный контроль без лишних плагинов | Нужно аккуратно обновлять тему или выносить код отдельно |
| Блокировка на сервере | Нужна жёсткая защита от внешних запросов | Можно случайно сломать легитимную интеграцию |
Вариант 1. Отключить через код
Если вам не нужен XML-RPC вообще, самый прозрачный способ — отключить его фильтром. Код лучше размещать в отдельном mu-plugin, а не в теме: так он не исчезнет при смене шаблона.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключает сам механизм XML-RPC на уровне WordPress. Если какой-то сервис продолжит стучаться в xmlrpc.php, он получит отказ.
Вариант 2. Закрыть доступ через сервер
Если цель — не просто выключить функцию, а ещё и убрать лишнюю нагрузку от ботов, можно заблокировать сам файл на уровне веб-сервера. Это особенно полезно, когда на сайт идёт поток мусорных запросов.
# Nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют .htaccess, но правило зависит от конфигурации хостинга. Если вы не уверены, что сервер действительно Apache с поддержкой .htaccess, лучше не вставлять готовый фрагмент вслепую.
Вариант 3. Отключить через плагин
Этот путь удобен, если нужно быстро протестировать эффект и при необходимости вернуть всё назад без правки кода. Но для долгосрочной эксплуатации лучше либо код, либо серверное правило. Плагин имеет смысл, когда вы уже используете его для других задач безопасности и не хотите плодить отдельные решения.
Пошаговое решение без сюрпризов
- Проверьте, есть ли обращения к
xmlrpc.phpв логах. - Уточните, не используют ли сайт внешние клиенты или сервисы публикации.
- Выберите способ отключения: код, сервер или плагин.
- Сделайте изменение сначала на staging-копии, если она есть.
- После внедрения проверьте, что endpoint больше не отвечает.
- Тестируйте не только главную страницу, но и все внешние сценарии: вход, публикацию, синхронизацию, мобильные приложения.
Если у вас есть доступ к staging, это лучший момент для проверки. XML-RPC часто ломает не сам сайт, а именно внешние сценарии, которые не видны в обычном браузере.
Как проверить, что отключение сработало
Проверка должна быть двойной: технической и функциональной. Техническая показывает, что endpoint закрыт. Функциональная — что ничего важного не отвалилось.
Техническая проверка
Снова запросите /xmlrpc.php через curl или браузер. Если вы блокировали на уровне WordPress, ответ должен быть отказом или пустым доступом в зависимости от способа. Если блокировали на сервере, часто будет 403 Forbidden.
curl -I https://example.com/xmlrpc.phpДополнительно проверьте журналы сервера: после блокировки поток обращений к этому файлу должен исчезнуть или перестать доходить до PHP.
Функциональная проверка
- попробуйте войти в админку и создать запись;
- если есть мобильное приложение, проверьте публикацию;
- если используется внешняя интеграция, отправьте тестовый запрос;
- посмотрите, не появились ли ошибки в логах плагинов синхронизации.
Если после отключения что-то сломалось, не возвращайте XML-RPC «на всякий случай» без анализа. Сначала найдите конкретную зависимость и решите, можно ли перевести её на REST API или другой способ авторизации.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом пропала публикация из внешнего сервиса
Это означает, что сервис действительно использовал XML-RPC, а не REST API. Решение — либо вернуть доступ точечно, либо перевести интеграцию на современный API, если сервис это поддерживает.
Поставили плагин, но endpoint всё равно отвечает
Так бывает, если плагин только фильтрует запросы внутри WordPress, а сам файл xmlrpc.php остаётся доступным на уровне веб-сервера. В этом случае добавьте серверную блокировку.
Закрыли доступ на сервере и сломали нужный сервис
Значит, вы не проверили зависимости заранее. Верните доступ, найдите источник запросов в логах и решите, можно ли ограничить доступ по IP, заменить сервис или перевести его на другой механизм.
Внесли код в тему и забыли про него
Если код лежит в functions.php, он исчезнет при смене темы. Для таких настроек лучше использовать mu-plugin или отдельный мини-плагин, чтобы решение не зависело от дизайна сайта.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC — не панацея, а один из слоёв защиты. Если сайт регулярно получает брутфорс по авторизации, стоит смотреть шире: ограничение попыток входа, двухфакторная аутентификация, нормальные пароли и обновления ядра, тем и плагинов.
С точки зрения производительности блокировка XML-RPC полезна тем, что уменьшает количество бессмысленных PHP-запросов. Это не ускорит сайт радикально, но снимет часть мусорной нагрузки, особенно если бот-активность высокая.
Если вам нужен более широкий набор мер по чистке сайта и отключению лишних WordPress-механизмов, имеет смысл смотреть в сторону инструментов, которые умеют управлять дублями, системными endpoint'ами и техническим мусором в одном месте. Например, у Clearfy Pro есть набор функций для такой гигиены сайта: https://wpshop.ru/plugins/clearfy.
Мини-чек-лист перед отключением
- проверили логи на обращения к
xmlrpc.php; - уточнили, нет ли мобильного приложения или внешней публикации;
- выбрали способ отключения, который можно быстро откатить;
- протестировали на staging, если он есть;
- после изменений проверили ответ endpoint и рабочие сценарии сайта.
Если нужна жёсткая защита от ботов, но при этом есть сомнения по зависимостям, начинайте с диагностики и только потом принимайте решение. В WordPress это почти всегда дешевле, чем потом разбирать, почему перестала публиковаться запись из внешнего сервиса.