XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно ломают мобильное приложение, внешнюю публикацию или интеграцию с сервисом автопостинга. Проблема в том, что этот интерфейс нужен не всем, но и не всегда можно убрать его без проверки зависимостей. Ниже — рабочий сценарий: как понять, используется ли XML-RPC, как отключить его безопасно и чем проверить результат.
Когда XML-RPC действительно стоит отключать
Если сайт не использует старые клиенты WordPress, внешние сервисы публикации и pingback/trackback, XML-RPC чаще всего только расширяет поверхность атаки. На практике его отключают, когда:
- нет мобильного приложения WordPress и удалённой публикации;
- не подключены сервисы автопостинга, которые работают через XML-RPC;
- нужен более жёсткий контроль над входящими запросами;
- на сайте уже есть REST API для нужных интеграций.
Если вы не уверены, сначала проверьте реальные обращения к xmlrpc.php, а не ориентируйтесь на общие рекомендации из интернета.
Диагностика: используется ли XML-RPC сейчас
Самый надёжный способ — посмотреть логи веб-сервера и запросы к файлу xmlrpc.php. Если у вас есть доступ к access log, ищите обращения по этому пути. Для Nginx это обычно делается через grep:
grep "xmlrpc.php" /var/log/nginx/access.logЕсли логов нет или доступ ограничен, можно временно добавить простую проверку в functions.php темы или в небольшой mu-plugin и посмотреть, кто стучится:
<?php
add_action('xmlrpc_call', function ($method) {
error_log('XML-RPC method: ' . $method);
});Этот вариант не отключает XML-RPC, а только помогает понять, какие методы вызываются. После проверки код нужно убрать.
Что искать в логах
- частые запросы к
/xmlrpc.phpс разных IP; - методы
system.multicall,wp.getUsersBlogs,metaWeblog.newPost; - ошибки 401/403/200 в ответ на обращения, которые вы не инициировали.
Если видите только случайные сканы, отключение обычно безопасно. Если есть легитимные вызовы от вашего сервиса, сначала перенесите интеграцию на REST API или другой способ авторизации.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, как вы управляете сайтом. Для продакшена лучше использовать способ, который не слетит при обновлении темы.
| Способ | Когда подходит | Минус |
|---|---|---|
| Плагин безопасности | Нужна быстрая настройка без кода | Лишняя зависимость от плагина |
| mu-plugin | Нужно надёжно и без привязки к теме | Требуется доступ к файлам |
| Правило на уровне сервера | Есть доступ к Nginx/Apache | Нужно аккуратно тестировать конфиг |
Вариант 1: отключить через mu-plugin
Это самый предсказуемый способ для WordPress. Создайте файл wp-content/mu-plugins/disable-xmlrpc.php и добавьте:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter('xmlrpc_enabled', '__return_false');Если папки mu-plugins нет, создайте её вручную. Такой файл загружается автоматически и не зависит от темы.
Вариант 2: блокировать запросы на уровне веб-сервера
Если у вас Nginx, можно отдать 403 для xmlrpc.php. Это полезно, когда вы хотите отсечь запросы ещё до загрузки WordPress:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверный уровень быстрее, но требует аккуратности: если у вас несколько сайтов или нестандартная конфигурация, проверьте, что правило не задело другие маршруты.
Вариант 3: использовать плагин, если нужен интерфейс без кода
Если вы не хотите править файлы, можно взять плагин, который умеет отключать XML-RPC вместе с другими техническими настройками. В линейке WPShop для таких задач уместен Clearfy Pro: он помогает централизованно управлять техническими опциями сайта, не размазывая их по теме и functions.php.
Но если задача только в XML-RPC, кодовый вариант обычно проще и прозрачнее.
Пошаговое решение без сюрпризов
- Проверьте логи на обращения к
xmlrpc.php. - Убедитесь, что не используете мобильное приложение WordPress и внешние клиенты публикации.
- Выберите способ отключения: mu-plugin или серверное правило.
- Очистите кеш сайта и CDN, если он есть.
- Проверьте ответ
xmlrpc.phpиз браузера или черезcurl.
Проверка через curl выглядит так:
curl -I https://example.com/xmlrpc.phpПосле отключения вы должны увидеть 403 Forbidden или другой отказ в доступе, а не обычный ответ WordPress. Если сервер возвращает 200 OK, значит правило не сработало или его перебивает другое правило.
Как проверить, что решение сработало
Проверка должна быть не только технической, но и функциональной. Смотрите на три уровня:
- HTTP-ответ —
xmlrpc.phpне должен открываться как рабочая точка входа; - логи — повторные обращения должны получать отказ;
- сайт — обычная авторизация, публикация и REST API продолжают работать.
Если у вас есть интеграция, которая раньше использовала XML-RPC, протестируйте её отдельно. Частая ошибка — отключить интерфейс и заметить проблему только после того, как перестали публиковаться записи из внешнего сервиса.
Мини-чек-лист после внедрения
- главная и внутренние страницы открываются без ошибок;
- админка WordPress доступна;
/wp-json/отвечает нормально;/xmlrpc.phpнедоступен или возвращает отказ;- кеш-плагин и CDN не отдают старую версию ответа.
Частые ошибки и как их исправить
Отключили XML-RPC в теме
Если правило добавлено в functions.php активной темы, оно исчезнет после смены темы. Для технической настройки лучше использовать mu-plugin или серверный конфиг.
Сломали внешнюю публикацию
Если сервис автопостинга или мобильное приложение продолжает использовать XML-RPC, отключение приведёт к ошибкам авторизации или публикации. В этом случае нужно либо оставить доступ, либо перевести интеграцию на REST API.
Проверили только в браузере
Открыть xmlrpc.php в браузере недостаточно. Некоторые правила блокируют только POST-запросы, а GET может отвечать иначе. Проверяйте именно curl -I и реальные методы, если есть доступ к тестовой среде.
Не очистили кеш
После изменения правил старый ответ может висеть в кеше CDN или плагина. Если кажется, что XML-RPC всё ещё доступен, сначала сбросьте кеш и повторите проверку.
Безопасность и производительность: что ещё имеет смысл сделать
Отключение XML-RPC не заменяет базовую защиту входа. Если на сайте много брутфорса, дополнительно проверьте:
- ограничение попыток входа;
- двухфакторную аутентификацию для админов;
- актуальность ядра, тем и плагинов;
- отсутствие лишних публичных endpoint-ов.
Если вы используете технический плагин для чистки сайта и отключения лишнего функционала, держите такие настройки в одном месте. Это проще сопровождать, чем набор разрозненных сниппетов в теме.
В итоге задача сводится к простому правилу: сначала выясняем, нужен ли XML-RPC реально, потом отключаем его способом, который не зависит от темы, и только после этого считаем работу завершённой. Иначе легко получить «защиту» ценой сломанной интеграции.