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