XML-RPC в WordPress часто отключают «на всякий случай», но на живом сайте это не всегда лучший ход. Проблема обычно не в самом файле xmlrpc.php, а в конкретных запросах: старые мобильные клиенты, внешние сервисы публикации, попытки брутфорса через system.multicall и лишняя нагрузка на сервер. Если понять, кто и зачем стучится в XML-RPC, можно убрать только лишнее и не сломать интеграции.
Ниже — рабочий сценарий: сначала диагностика, потом точечное отключение, затем проверка результата. Подходит для сайтов, где нужно сохранить контроль над безопасностью и не потерять внешние подключения.
Когда XML-RPC действительно мешает
На практике это видно по нескольким признакам. В логах веб-сервера появляются частые POST-запросы к /xmlrpc.php, иногда с одинаковыми payload'ами. На слабых хостингах это может давать лишнюю нагрузку даже без успешных авторизаций. Второй типичный сценарий — сторонний сервис больше не используется, но метод XML-RPC по-прежнему открыт и принимает запросы без пользы.
Есть и обратная ситуация: сайт использует Jetpack, старое приложение WordPress для публикации, внешнюю синхронизацию или мониторинг, который всё ещё опирается на XML-RPC. В этом случае грубое отключение ломает интеграцию, и проблема всплывает уже после деплоя.
Что проверить в первую очередь
- есть ли в access log частые обращения к
xmlrpc.php; - используются ли Jetpack, мобильные клиенты WordPress или внешняя публикация;
- есть ли в логах ошибки авторизации или повторяющиеся запросы
system.multicall; - не закрыт ли уже XML-RPC на уровне WAF, nginx, Apache или плагина безопасности;
- не дублируется ли защита: например, XML-RPC уже блокируется сервером, а в WordPress стоит ещё и фильтр, который мешает отладке.
Диагностика: откуда идут запросы
Если у вас есть доступ к логам веб-сервера, начните с поиска обращений к xmlrpc.php. На nginx это обычно access log, на Apache — аналогично. Важно смотреть не только факт обращения, но и частоту, IP-адреса и коды ответа. Если запросы идут с разных адресов и с высокой частотой, это похоже на сканирование или брутфорс.
Для быстрой проверки можно временно включить логирование на уровне WordPress и посмотреть, не вызывает ли XML-RPC сторонний код. Но чаще достаточно серверных логов и списка активных интеграций.
# Пример поиска обращений к xmlrpc.php в access log
# nginx / Apache: подстройте путь под свой сервер
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50
Если нужно понять, какие методы вызываются, можно на короткое время добавить фильтр в mu-plugin или в functions.php дочерней темы. Это не для постоянной работы, а именно для диагностики.
<?php
add_filter('xmlrpc_methods', function ($methods) {
error_log('XML-RPC methods loaded: ' . implode(', ', array_keys($methods)));
return $methods;
});
Такой код не покажет весь трафик, но поможет убедиться, что XML-RPC вообще задействован на стороне WordPress. После проверки фильтр нужно убрать.
Как отключить только лишнее, а не всё подряд
Если XML-RPC нужен частично, лучше не рубить его целиком. Например, можно запретить опасные или ненужные методы, а остальные оставить. Это полезно, когда сайт всё ещё использует внешнюю публикацию, но вам не нужен массовый перебор логинов через system.multicall.
Ниже пример, который убирает метод system.multicall. Это не универсальная защита, но на практике сокращает один из самых частых векторов злоупотребления.
<?php
add_filter('xmlrpc_methods', function ($methods) {
unset($methods['system.multicall']);
return $methods;
});
Если задача — полностью отключить XML-RPC, используйте фильтр xmlrpc_enabled. Это штатный механизм WordPress, без выдуманных хуков и костылей.
<?php
add_filter('xmlrpc_enabled', '__return_false');
Такой вариант проще всего внедрить в маленький must-use плагин или в собственный плагин безопасности. Если вы правите тему, помните: при смене темы защита исчезнет. Для системной настройки тема — плохое место.
Когда лучше блокировать на сервере
Если XML-RPC не нужен вообще, блокировка на уровне nginx или Apache снимает нагрузку ещё до запуска WordPress. Это полезно на сайтах с большим количеством мусорных запросов. Но у серверной блокировки есть минус: если позже понадобится интеграция, вы можете забыть, где именно стоит правило.
Пример для nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Для Apache обычно используют правило в .htaccess или конфигурации виртуального хоста:
<Files "xmlrpc.php">
Require all denied
</Files>
Если у вас уже стоит плагин безопасности, проверьте, не дублирует ли он это правило. Двойная блокировка сама по себе не ошибка, но при поиске причин отказа она мешает понять, где именно сработал запрет.
Сравнение подходов: плагин, код или сервер
| Подход | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин безопасности | Быстро включить, не нужен код | Зависимость от плагина, лишняя нагрузка | Если уже используете security-плагин и нужен простой контроль |
Код через xmlrpc_enabled | Точно и прозрачно, без лишних интерфейсов | Нужно аккуратно хранить код | Если нужен управляемый запрет на уровне WordPress |
| Блокировка на сервере | Отсекает запросы до PHP | Можно забыть о правиле при переносе | Если XML-RPC не нужен вообще и важна экономия ресурсов |
Пошаговое решение без лишнего риска
- Проверьте логи и список интеграций, которые могут использовать XML-RPC.
- Если нужен только один сценарий, отключите опасные методы через
xmlrpc_methods. - Если XML-RPC не нужен, отключите его через
xmlrpc_enabledили серверное правило. - После изменения протестируйте входящие запросы и внешние сервисы.
- Уберите временный диагностический код и зафиксируйте изменение в репозитории или заметках по инфраструктуре.
Как проверить, что решение сработало
Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере: при полном отключении вы не должны видеть рабочий ответ метода. Но этого недостаточно, потому что браузерный GET не имитирует реальный XML-RPC POST.
Надёжнее отправить тестовый POST-запрос. Если 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>
<params></params>
</methodCall>'
После внедрения проверьте ещё три вещи:
- в логах больше нет успешных обращений к
xmlrpc.php; - Jetpack или другой нужный сервис не потерял связь;
- страницы сайта и админка работают без побочных ошибок.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом сломали интеграцию
Это происходит, когда заранее не проверили, чем сайт реально пользуется. Если нужен Jetpack, мобильное приложение WordPress или внешний сервис публикации, сначала тестируйте на staging. Если интеграция уже сломалась, верните XML-RPC и отключайте только лишние методы.
Поставили запрет в теме
Такой код исчезает при смене темы и часто теряется при обновлении. Для системной защиты используйте собственный плагин или mu-plugin. Это особенно важно, если сайт поддерживает несколько тем или часто обновляется.
Дублируете защиту в нескольких местах и не понимаете, что сработало
Если XML-RPC закрыт и в WordPress, и на сервере, и в плагине безопасности, отладка становится бессмысленной. Оставьте один основной механизм и один резервный, но документируйте, где именно стоит блокировка.
Проверяете только GET-запросом
XML-RPC работает через POST. Если вы просто открыли xmlrpc.php в браузере, это не доказывает, что защита корректно отсекает реальные запросы. Используйте curl или тестовый клиент.
Практика безопасности и производительности
Если сайт регулярно атакуют через XML-RPC, имеет смысл дополнительно ограничить частоту запросов на уровне WAF или reverse proxy. Это не замена отключению, но полезный слой защиты. На слабом хостинге даже неуспешные запросы могут съедать ресурсы, особенно если их много.
Для сайтов, где XML-RPC не нужен, самый чистый вариант — серверная блокировка плюс проверка, что никакие внешние сервисы не используют этот канал. Для сайтов с частичной зависимостью от XML-RPC лучше оставить WordPress-уровень и отключить только опасные методы. Так проще сопровождать изменение и быстрее вернуть нужную функциональность, если она вдруг понадобится.
Если вам нужно регулярно чистить сайт от дублей, мусора и лишних технических сущностей, можно посмотреть в сторону Clearfy Pro: у него есть инструменты для технической оптимизации и отключения части лишнего функционала без ручного вмешательства в каждую мелочь. Но даже в этом случае логи и проверка после изменений остаются обязательными.