XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно ломают синхронизацию с Jetpack, мобильным приложением или внешним сервисом публикации. Если задача не в полном запрете, а в точечном ограничении атак, лучше сначала понять, кто именно использует xmlrpc.php, и только потом резать доступ.
Когда XML-RPC действительно стоит ограничить
Чаще всего проблема выглядит так: в логах много запросов к /xmlrpc.php, сайт получает лишнюю нагрузку, а в панели безопасности видно подбор паролей через метод system.multicall. Это не значит, что XML-RPC нужно удалять без разбора. На живом сайте он может использоваться для:
- Jetpack и связанных с ним функций;
- старых мобильных клиентов WordPress;
- удалённой публикации через внешние редакторы;
- некоторых интеграций, которые до сих пор опираются на XML-RPC.
Если хотя бы один из этих сценариев нужен, полное отключение через код или серверный запрет может создать побочные эффекты. Поэтому сначала нужна диагностика.
Диагностика: кто обращается к xmlrpc.php
Самый полезный шаг — посмотреть доступы в логах веб-сервера. Ищите запросы к xmlrpc.php, особенно с повторяющимися POST-запросами и одинаковыми IP. Если есть доступ к командной строке, можно быстро отфильтровать обращения:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если у вас Apache, путь к логам может отличаться, но логика та же: смотрим частоту, IP и статус-коды. Отдельно полезно проверить, не идут ли запросы от Jetpack или от вашего собственного приложения. Для этого сравните время обращений с моментами, когда вы публикуете записи или синхронизируете сайт.
Что должно насторожить
- много POST-запросов в минуту с одного IP;
- серии неудачных авторизаций;
- запросы к
system.multicall; - рост нагрузки без видимой причины;
- ошибки в Jetpack после тестового отключения XML-RPC.
Пошаговое решение: сначала ограничить, потом отключать
Если цель — защититься от brute force, не обязательно сразу блокировать всё. Есть три рабочих варианта: ограничение на уровне сервера, отключение через WordPress-хук и точечная блокировка только для подозрительных методов.
| Подход | Что делает | Плюс | Минус |
|---|---|---|---|
| Серверный запрет | Блокирует xmlrpc.php на уровне nginx/Apache | Быстро и жёстко | Ломает Jetpack и внешние клиенты |
| WordPress-хук | Отключает XML-RPC изнутри WordPress | Проще тестировать | Не защищает от всех запросов до загрузки WP |
| Фильтрация методов | Оставляет нужные вызовы, режет опасные | Гибко | Нужно аккуратно протестировать |
Вариант 1: отключить XML-RPC через WordPress
Если вы точно не используете Jetpack, мобильные приложения и удалённую публикацию, можно отключить XML-RPC через фильтр xmlrpc_enabled. Добавьте код в плагин сайта или в functions.php дочерней темы:
add_filter( 'xmlrpc_enabled', '__return_false' );Это простой и понятный вариант. Но он не отвечает на вопрос, кто именно ломается после отключения. Поэтому после внедрения обязательно проверьте Jetpack и любые внешние интеграции.
Вариант 2: заблокировать только опасные методы
Если XML-RPC нужен, но вы хотите убрать типичный вектор атаки, можно запретить отдельные методы. Например, system.multicall часто используют для массового перебора логинов. Такой подход не является универсальной защитой, но снижает шум от атак:
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['system.multicall'] );
unset( $methods['pingback.ping'] );
return $methods;
} );Этот вариант полезен, если вам нужен XML-RPC для конкретной интеграции, но не нужны pingback и массовые вызовы. После изменения проверьте, не завязаны ли на pingback старые сценарии уведомлений.
Вариант 3: блокировка на уровне nginx
Если XML-RPC не нужен вообще, самый жёсткий и дешёвый по ресурсам способ — отрезать доступ на веб-сервере. Для nginx это выглядит так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой запрет не даёт запросу дойти до WordPress, что полезно при постоянных атаках. Но если позже понадобится Jetpack, правило придётся убрать или ослабить.
Как проверить, что решение сработало
Проверка должна быть не только «страница открывается». Нужны три теста:
- Откройте
/xmlrpc.phpв браузере или черезcurlи убедитесь, что поведение соответствует выбранному варианту. - Проверьте Jetpack: синхронизацию, статистику, публикацию и подключение к WordPress.com.
- Посмотрите логи сервера через 10–15 минут после изменения: число обращений к
xmlrpc.phpдолжно либо исчезнуть, либо перестать создавать нагрузку.
Для быстрой проверки через CLI можно использовать:
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали файл на уровне nginx, ожидайте 403 Forbidden. Если отключали через WordPress, ответ может отличаться в зависимости от конфигурации, но сам сервис должен перестать принимать XML-RPC-вызовы.
Частые ошибки и как их исправить
Отключили XML-RPC, а Jetpack перестал работать
Причина простая: Jetpack использует XML-RPC для части функций. Решение — либо вернуть XML-RPC, либо перейти на более мягкую фильтрацию методов вместо полного запрета.
Поставили запрет в .htaccess, но запросы всё равно идут
Так бывает, если сайт работает на nginx или если правило не применяется к нужному виртуальному хосту. Проверьте стек сервера и место, где реально обрабатывается запрос.
Добавили код в тему, а после обновления он пропал
Это типичная ошибка. Для таких правок лучше использовать mu-plugin или отдельный мини-плагин сайта, а не functions.php активной темы.
Отключили XML-RPC, но атаки в логах остались
Это нормально: боты продолжают стучаться по старому адресу, даже если получают отказ. Важен не сам факт запросов, а то, что они больше не доходят до логики WordPress и не создают лишнюю нагрузку.
Практические советы по безопасности и производительности
Если у вас уже есть плагин безопасности, сначала проверьте, не умеет ли он ограничивать XML-RPC без отдельного кода. Но не ставьте несколько решений, которые делают одно и то же: двойная блокировка часто только усложняет диагностику.
- Не отключайте XML-RPC на продакшене без теста на staging-копии.
- Если нужен только Jetpack, проверьте минимальный набор функций, а не только факт подключения.
- После изменения очистите кеш страницы и кеш на уровне CDN, если он есть.
- Если атаки массовые, полезнее блокировать их на уровне WAF или сервера, чем нагружать WordPress обработкой запроса.
Для сайтов, где важна чистка лишних поверхностей атаки, иногда удобнее использовать набор инструментов вроде Clearfy Pro: он помогает убирать часть технического мусора и упрощает контроль над лишними возможностями WordPress. Но даже в этом случае XML-RPC лучше проверять отдельно, потому что последствия зависят от конкретного стека и подключённых сервисов.
Что делать, если нужен компромиссный режим
Компромиссный сценарий обычно выглядит так: XML-RPC не нужен для публикации, но нужен для одного внешнего сервиса. Тогда не отключайте его полностью. Сначала уберите опасные методы, затем ограничьте доступ по IP на уровне сервера или через WAF, если сервис работает с фиксированными адресами. Это даёт более предсказуемый результат, чем жёсткий запрет для всех.
Если после изменений вы видите, что внешняя интеграция всё ещё работает, а лишние запросы не создают нагрузку, значит решение выбрано правильно. Если же появляются ошибки авторизации, проблемы с публикацией или отваливается синхронизация, откатывайте последний шаг и переходите к более мягкой фильтрации.