XML-RPC в WordPress часто оставляют включённым по привычке, хотя на большинстве сайтов он не нужен. Проблема не только в лишней поверхности атаки: через него могут идти брутфорс-атаки, pingback-спам и запросы, которые создают нагрузку на сайт. Если вы не используете мобильное приложение WordPress, внешние публикации через старые клиенты или интеграции, завязанные именно на XML-RPC, его обычно имеет смысл закрыть.
Ниже — рабочие способы отключения, как проверить, что всё сработало, и где чаще всего ломают сайт, пытаясь «просто запретить xmlrpc.php».
Когда XML-RPC действительно стоит отключать
Сначала полезно понять, есть ли у вас реальная зависимость от этого интерфейса. XML-RPC нужен не всем подряд, а только в конкретных сценариях. Если сайт живёт обычной админкой, REST API и современными плагинами, то в большинстве случаев он не используется.
Типичные признаки, что XML-RPC не нужен
- Вы не публикуете записи из сторонних клиентов и не используете старое мобильное приложение WordPress.
- На сайте нет интеграций, которые явно требуют XML-RPC.
- В логах видны массовые обращения к
/xmlrpc.phpбез полезной нагрузки. - Сайт получает много попыток авторизации через
system.multicallили pingback-запросы.
Когда отключать нельзя без проверки
Если у вас есть внешние сервисы, которые синхронизируют публикации, комментарии или медиаконтент через XML-RPC, сначала проверьте их документацию. Иногда интеграция выглядит «старой», но всё ещё работает именно через этот механизм. В таком случае лучше ограничить доступ на уровне сервера или заменить интеграцию, чем сломать рабочий процесс.
Диагностика: как понять, что XML-RPC используется
Перед отключением стоит проверить, не обращается ли к нему кто-то из ваших сервисов. Самый простой способ — посмотреть логи веб-сервера и обращения к xmlrpc.php. Если доступа к логам нет, можно временно открыть страницу напрямую и посмотреть ответ сервера.
curl -I https://example.com/xmlrpc.phpЕсли файл доступен, сервер обычно вернёт ответ с кодом 200 или 405 в зависимости от конфигурации. Это ещё не означает, что XML-RPC активен для полезных запросов, но показывает, что точка входа не закрыта.
Для более точной проверки можно отправить тестовый POST-запрос. Если XML-RPC работает, WordPress обычно отвечает сообщением о том, что нужны корректные данные метода. Если доступ закрыт, вы увидите 403, 404 или другой запрет на уровне сервера или плагина безопасности.
curl -s -X POST https://example.com/xmlrpc.php -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'Как отключить XML-RPC: три рабочих подхода
Универсального способа нет: выбор зависит от того, где вы хотите контролировать доступ — в WordPress, на сервере или через плагин. Ниже — сравнение по практике.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Контроль внутри WordPress, легко откатить | Не защищает от лишних обращений на уровне веб-сервера |
| Правило на сервере | Режет запросы раньше, меньше нагрузки | Нужно иметь доступ к конфигу Nginx/Apache |
| Плагин безопасности | Быстро включить без кода | Зависимость от плагина и его настроек |
Способ 1. Отключить XML-RPC кодом
Если нужен быстрый и прозрачный вариант, добавьте фильтр в functions.php дочерней темы или, лучше, в mu-plugin. Так код не потеряется при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно, но запросы всё равно будут доходить до PHP. Если на сайт идёт много мусорного трафика, лучше дополнить это серверным правилом.
Способ 2. Закрыть xmlrpc.php на сервере
Если у вас 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 через плагин безопасности. Удобство здесь в том, что настройка обычно делается в пару кликов, а отключение легко откатить. Но важно понимать, что плагин не должен быть единственной линией защиты, если сайт уже под атакой.
Если у вас уже стоит плагин для технической чистки и SEO-оптимизации, например Clearfy Pro, проверьте, есть ли в нём отдельная настройка для отключения XML-RPC и других лишних сервисов. Это удобно, когда вы хотите собрать базовую гигиену сайта в одном месте, а не держать несколько мелких плагинов.
Пошаговое решение без лишнего риска
- Проверьте, использует ли сайт XML-RPC сейчас: логи, интеграции, тестовый запрос.
- Выберите способ отключения: код, сервер или плагин.
- Внесите изменение сначала на staging, если он есть.
- Проверьте ответ
/xmlrpc.phpпосле изменения. - Посмотрите логи ошибок и авторизации в течение ближайшего времени.
Если нужен минимальный и безопасный путь, я бы делал так: сначала фильтр xmlrpc_enabled, затем, если сайт часто атакуют, добавлял бы блокировку на сервере. Это даёт и логическую, и сетевую защиту.
Как проверить, что отключение сработало
Проверка нужна не только ради галочки. Иногда XML-RPC «отключают», но забывают про кеш, CDN или серверное правило, которое не применилось. В итоге сайт выглядит защищённым только на бумаге.
Проверка через браузер и curl
Откройте https://example.com/xmlrpc.php в браузере. Если всё закрыто на уровне сервера, вы увидите запрет доступа или 404. Если отключение сделано только через WordPress, страница может отвечать иначе, но полезные XML-RPC-методы работать не будут.
Для более надёжной проверки используйте POST-запрос:
curl -i -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'Если вы видите 403 или 404 — это хороший признак. Если сервер отвечает 200 и XML с ошибкой WordPress, значит точка входа ещё жива и работает на уровне приложения.
Проверка по логам
После отключения посмотрите access log и error log. Цель — убедиться, что запросы к xmlrpc.php не проходят дальше, чем нужно. Если у вас много ботов, полезно сравнить количество обращений до и после изменения. Не ради статистики, а чтобы понять, не создаёт ли сайт лишнюю нагрузку на PHP-FPM или Apache.
Частые ошибки и как их исправить
- Отключили XML-RPC в теме. При смене темы защита исчезнет. Перенесите код в mu-plugin или в отдельный функциональный плагин.
- Поставили правило в .htaccess, но сайт на Nginx. Правило просто не сработает. Для Nginx нужно править конфиг сервера.
- Сломали внешнюю интеграцию. Проверьте, не использует ли её мобильное приложение, сервис публикации или старый клиент.
- Смотрят только на браузерный GET-запрос. XML-RPC работает через POST, поэтому тестировать нужно именно его.
- Не очистили кеш. После изменения правил CDN или серверный кеш может показывать старый ответ.
Безопасность и производительность: что ещё имеет смысл сделать рядом
Отключение XML-RPC — это не замена нормальной защиты входа. Если сайт регулярно атакуют, проверьте ещё несколько вещей: ограничение попыток входа, двухфакторную аутентификацию для админов, актуальность ядра и плагинов, а также отсутствие лишних публичных endpoint-ов. Если у вас есть REST API-эндпоинты от кастомных плагинов, их тоже стоит проверить на избыточную открытость.
С точки зрения производительности закрытие XML-RPC полезно тем, что убирает один из популярных каналов мусорных запросов. Это не ускорит сайт магически, но снизит количество бесполезных обращений к PHP, особенно на небольших хостингах и при слабом лимите процессов.
Если нужно откатить изменение
Откат должен быть таким же простым, как и включение защиты. Если вы использовали фильтр xmlrpc_enabled, просто удалите его. Если закрывали на сервере — уберите правило и проверьте, не осталось ли его в нескольких местах: в основном конфиге, в include-файле или в панели хостинга. Если использовали плагин, отключите именно его настройку, а не весь плагин, если он нужен для других задач.
Самый надёжный подход — менять только один слой за раз и сразу проверять результат. Тогда вы быстро поймёте, что именно сработало: WordPress, веб-сервер или плагин безопасности.