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