Если в логах регулярно мелькают запросы к /xmlrpc.php, это не всегда критическая проблема, но почти всегда лишняя поверхность атаки. Чаще всего по этому endpoint идут попытки перебора паролей через system.multicall, а иногда — шум от внешних сервисов, которые давно можно заменить на REST API или нативные интеграции.
Ниже — практический разбор: когда XML-RPC можно отключать, как это сделать без поломки сайта и как проверить, что защита реально работает.
Когда XML-RPC нужен, а когда его можно отключить
XML-RPC исторически использовался для удалённой публикации, мобильного приложения WordPress и некоторых внешних клиентов. В современных проектах он часто не нужен вообще. Но перед отключением стоит проверить, не завязан ли на него конкретный сценарий.
Проверьте зависимости
- используется ли мобильное приложение WordPress для публикации;
- подключён ли внешний сервис, который отправляет записи через XML-RPC;
- есть ли старые интеграции с Jetpack или сторонними клиентами;
- не настроена ли синхронизация через
xmlrpc.phpв старом плагине или теме.
Если ничего из этого не используется, отключение XML-RPC обычно безопасно. Для большинства сайтов это просто уменьшение атакующей поверхности.
Диагностика: как понять, что проблема именно в XML-RPC
Сначала не трогайте код. Посмотрите, действительно ли endpoint атакуют. В access-логах веб-сервера обычно видны повторяющиеся POST-запросы на /xmlrpc.php. Если включён fail2ban, можно увидеть частые срабатывания на одинаковые IP или на шаблонные запросы с system.multicall.
Типичные признаки:
- много POST-запросов к
/xmlrpc.phpбез нормального пользовательского трафика; - попытки авторизации с разными логинами;
- нагрузка на PHP без видимого роста посещаемости;
- в логах безопасности — повторяющиеся ошибки аутентификации через XML-RPC.
Если сайт медленно отвечает именно в моменты таких запросов, отключение endpoint может заметно снизить шум. Но если проблема в слабом хостинге или тяжёлом плагине, одного запрета XML-RPC недостаточно.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, насколько жёстко нужно закрыть доступ. Для обычного сайта достаточно отключения на уровне WordPress. Если атаки массовые, лучше дополнительно закрыть endpoint на уровне веб-сервера или WAF.
| Способ | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| PHP-фильтр в теме или mu-plugin | Нужно быстро и точечно | Просто откатить, не требует панели хостинга | Запрос всё равно доходит до WordPress |
| Правило в Nginx/Apache | Есть доступ к конфигу сервера | Отсекает запросы раньше PHP | Нужен доступ к серверу |
| Плагин безопасности | Нужен интерфейс без кода | Удобно для админа | Лишняя зависимость от плагина |
Вариант 1: отключить XML-RPC через код
Самый аккуратный способ — добавить фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так вы не потеряете настройку при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. Если какой-то внешний сервис продолжит стучаться в xmlrpc.php, он получит отказ уже от ядра.
Если нужен более жёсткий запрет, можно дополнительно отдать 403 на сам файл:
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );Но на практике первый вариант обычно достаточно понятен и безопасен.
Вариант 2: закрыть XML-RPC на уровне сервера
Если у вас Nginx, можно заблокировать доступ к файлу напрямую:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache в .htaccess можно использовать правило доступа:
<Files xmlrpc.php>
Require all denied
</Files>Этот способ полезен, когда боты создают заметную нагрузку и вы хотите отрезать их до запуска PHP. Но если сайт работает за CDN или reverse proxy, проверьте, что правило применяется именно на том уровне, где реально обрабатывается запрос.
Вариант 3: использовать плагин безопасности
Если на сайте уже стоит плагин безопасности, проверьте, умеет ли он отключать XML-RPC без дополнительных костылей. Это удобно для администраторов, которым проще включить опцию в интерфейсе, чем править код. Но не ставьте отдельный плагин только ради одной функции, если задача решается одной строкой кода.
Пошаговое решение без поломки сайта
- Проверьте, используется ли XML-RPC внешними сервисами или мобильным приложением.
- Сделайте резервную копию файлов и базы.
- Добавьте
add_filter( 'xmlrpc_enabled', '__return_false' );в mu-plugin или дочернюю тему. - Очистите кеш сайта и CDN, если он есть.
- Проверьте, не ломается ли публикация, синхронизация или интеграции.
- Посмотрите логи и убедитесь, что запросы к
/xmlrpc.phpполучают отказ.
Если после отключения что-то перестало работать, значит, зависимость была реальной. В этом случае лучше не включать XML-RPC обратно для всех, а точечно заменить интеграцию на REST API или другой способ обмена данными.
Как проверить, что защита сработала
Проверка должна быть не только визуальной. Откройте https://ваш-домен.ru/xmlrpc.php в браузере или отправьте POST-запрос через curl. Если endpoint закрыт, вы не должны получить рабочий ответ для XML-RPC-вызова.
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 Forbidden, 404 Not Found или отказ на уровне WordPress. Главное — запрос не должен проходить как рабочий XML-RPC-метод.
Дополнительно проверьте:
- логи сервера — запросы к
/xmlrpc.phpбольше не доходят до PHP, если блокировка на уровне Nginx/Apache; - админку — публикация записей и вход в панель работают как раньше;
- внешние сервисы — нет ли ошибок синхронизации после отключения.
Частые ошибки и как их исправить
Отключили XML-RPC, но атаки продолжаются
Это нормально, если боты продолжают стучаться в endpoint. Важно не то, что запросы приходят, а то, что они не проходят дальше. Если нагрузка всё ещё заметна, переносите блокировку на уровень веб-сервера или WAF.
Сломалась публикация из мобильного приложения
Значит, приложение действительно использовало XML-RPC. В таком случае либо возвращайте доступ, либо переводите рабочий процесс на другой инструмент. Для редакции это обычно лучший момент, чтобы отказаться от старого сценария.
Поставили плагин безопасности и забыли про кеш
Если на сайте есть page cache или CDN, старые ответы могут ещё какое-то время быть доступны. После изменения настройки обязательно очищайте кеш сайта, серверный кеш и CDN.
Закрыли файл, но не проверили конфиг сервера
Иногда правило в .htaccess не работает, если сайт обслуживается Nginx без Apache-совместимого слоя. Тогда нужно править именно конфиг Nginx или использовать блокировку на уровне панели хостинга.
Что ещё стоит сделать для безопасности
Отключение XML-RPC — не замена нормальной защите входа. Если на сайте уже идут попытки перебора, добавьте базовые меры:
- ограничьте число попыток входа;
- включите двухфакторную аутентификацию для админов;
- проверьте, не используются ли слабые пароли у редакторов;
- уберите лишние админские аккаунты;
- следите за логами 401/403 и аномальной активностью.
Если нужен более широкий набор технической чистки и SEO-оптимизации, иногда удобнее закрывать такие вещи через один инструмент, а не собирать набор разрозненных плагинов. Например, Clearfy Pro от WPShop закрывает часть типовых задач по чистке сайта и отключению лишнего функционала: https://wpshop.ru/plugins/clearfy.
Но если задача только в XML-RPC, не усложняйте стек без необходимости: одна проверенная настройка и контроль логов обычно лучше, чем ещё один тяжёлый плагин.