Как отключить открытые XML-RPC запросы в WordPress и оставить их для нужных сервисов

Полностью рубить XML-RPC на живом сайте — не всегда лучший вариант. Если у вас подключены мобильное приложение WordPress, внешние публикационные сервисы или старые интеграции, полный запрет ломает сценарии, которые реально используются. Но оставлять XML-RPC открытым для всех запросов тоже плохая идея: этот интерфейс часто используют для перебора логинов, массовых запросов и лишней нагрузки.

Ниже — практический вариант: сначала понять, нужен ли XML-RPC вообще, затем ограничить его точечно и проверить, что вы не сломали рабочие интеграции.

Когда XML-RPC действительно проблема

XML-RPC в WordPress — это не «ошибка», а старый интерфейс удалённого доступа. Проблема начинается, когда он доступен всем подряд, а сайт не использует его по назначению. На практике это видно по нескольким признакам:

• в логах появляются частые запросы к /xmlrpc.php;
• на хостинге растёт число 403/200 запросов без понятного источника;
• в панели безопасности видно попытки брутфорса через system.multicall;
• мобильное приложение WordPress или внешняя публикация перестают работать после грубого отключения;
• сайт на слабом хостинге начинает проседать по CPU из-за лишних обращений.

Что важно проверить до изменений

Не начинайте с блокировки наугад. Сначала ответьте на три вопроса:

• используете ли вы мобильное приложение WordPress;
• есть ли внешние сервисы, которые публикуют записи через XML-RPC;
• есть ли старые интеграции, которые завязаны на этот интерфейс.

Если ответ на все три вопроса «нет», можно смело отключать XML-RPC полностью. Если хотя бы один ответ «да», лучше ограничить доступ и оставить только нужные сценарии.

Диагностика: как понять, кто стучится в xmlrpc.php

Самый простой способ — посмотреть access log веб-сервера. На Nginx это обычно /var/log/nginx/access.log, на Apache — аналогичный лог виртуального хоста. Ищите обращения к xmlrpc.php:

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

Если запросов много и они идут с разных IP, это уже не похоже на ваш легитимный трафик. Обратите внимание на повторяющиеся POST-запросы и на методы вроде system.multicall в теле запроса — это типичный паттерн перебора.

Если у вас установлен плагин безопасности, проверьте его журнал блокировок. Но не полагайтесь только на него: иногда плагин уже режет запросы, а нагрузка всё равно успевает попасть на PHP-слой.

Рабочие способы: полный запрет или точечное ограничение

Есть три нормальных подхода. Выбор зависит от того, нужен ли вам XML-RPC вообще.

Вариант 1. Полностью отключить XML-RPC через код

Если интерфейс не нужен, самый прямой способ — отключить его фильтром. Добавьте код в functions.php дочерней темы или в небольшой mu-plugin.

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Это блокирует сам механизм XML-RPC на уровне WordPress. Запросы к /xmlrpc.php перестанут обслуживаться штатно.

Плюс этого варианта — простота. Минус — если позже понадобится внешняя публикация, придётся возвращать код назад.

Вариант 2. Заблокировать доступ на уровне Nginx

Если сайт работает на Nginx, лучше рубить лишние запросы до PHP. Это экономит ресурсы и уменьшает шанс, что сайт будет нагружен перебором логинов.

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Такой блок подходит, если XML-RPC не нужен вообще. Если нужен только для отдельных сценариев, этот вариант слишком жёсткий.

Вариант 3. Оставить доступ, но ограничить по IP

Если XML-RPC нужен только с одного-двух адресов, например с офисного IP или с сервера интеграции, ограничьте доступ на уровне веб-сервера. Для Nginx это можно сделать через allow/deny:

location = /xmlrpc.php {
    allow 203.0.113.10;
    allow 198.51.100.25;
    deny all;
}

Это уже рабочий компромисс: внешние сервисы продолжают работать, а случайные запросы с интернета отсеиваются до PHP.

Если нужен только один сервис: как не сломать интеграцию

Частая ошибка — отключить XML-RPC целиком, а потом обнаружить, что редактор на телефоне больше не публикует записи. Если у вас есть конкретный сервис, который использует XML-RPC, сначала проверьте, можно ли заменить его на REST API. У WordPress REST API обычно лучше поддерживается современными приложениями и плагинами.

Если замена невозможна, оставляйте XML-RPC, но:

• ограничьте доступ по IP;
• используйте сложные пароли и двухфакторную аутентификацию для админов;
• уберите лишние учётные записи с правами публикации;
• проверьте, не делает ли сервис лишние запросы по расписанию.

Если вы используете плагин безопасности, проверьте, не блокирует ли он нужный сервис по User-Agent или по частоте запросов. Иногда проблема не в XML-RPC как таковом, а в слишком агрессивных правилах.

Проверка результата после внедрения

После изменения конфигурации не ограничивайтесь открытием главной страницы. Проверьте именно тот сценарий, который вы меняли.

Что проверить вручную

• открывается ли /xmlrpc.php в браузере или через curl;
• работает ли мобильное приложение WordPress, если оно вам нужно;
• проходит ли публикация через внешний сервис;
• нет ли новых ошибок в логах веб-сервера и PHP;
• не выросло ли число 403/500 ответов после изменения правил.

Для быстрой проверки можно отправить запрос через curl и посмотреть ответ:

curl -i https://example.com/xmlrpc.php

Если вы отключили XML-RPC полностью, ожидаемым результатом будет отказ в доступе или нерабочий ответ, в зависимости от способа блокировки. Если ограничили по IP, проверьте запрос как с разрешённого адреса, так и с внешнего IP.

Что смотреть в логах

После внедрения в логах не должно быть всплеска ошибок, связанных с xmlrpc.php. Если вы видите много 403, это нормально только в том случае, когда блокировка действительно срабатывает на чужие запросы. Если же 403 идут с вашего IP или от интеграции, значит правило слишком жёсткое.

Частые ошибки и как их исправить

• Отключили XML-RPC через плагин и забыли про интеграции. Решение: сначала составьте список сервисов, которые публикуют или читают данные через WordPress.
• Заблокировали файл на уровне сервера, но оставили доступ через другой виртуальный хост или CDN. Решение: проверьте именно тот домен, который обслуживает сайт, и правила на уровне CDN/WAF.
• Сделали правило в .htaccess, но сайт работает на Nginx. Решение: для Nginx используйте конфиг сервера, а не Apache-синтаксис.
• Проверили только главную страницу и решили, что всё работает. Решение: тестируйте именно /xmlrpc.php и рабочий сценарий публикации.
• Оставили XML-RPC открытым, но надеялись, что плагин безопасности всё решит. Решение: переносите блокировку ближе к веб-серверу, если интерфейс не нужен.

Безопасность и производительность: что ещё имеет смысл сделать

Если вы уже трогаете XML-RPC, имеет смысл посмотреть и на соседние точки риска. Для сайта на WordPress обычно полезно:

• ограничить число попыток входа;
• включить двухфакторную аутентификацию для администраторов;
• убрать неиспользуемые плагины и темы;
• проверить права на файлы и доступ к wp-config.php;
• следить за логами 404 и 403, чтобы не пропускать атаки и мусорный трафик.

Если вам нужно не только отключить XML-RPC, но и почистить сайт от лишних технических дублей, служебных сущностей и мусорных настроек, такие задачи удобно решать комплексно. Например, в Clearfy Pro есть набор инструментов для технической чистки WordPress, но использовать его стоит только там, где вы понимаете, что именно отключаете и зачем: лишняя автоматизация без проверки часто ломает нужные сценарии.

Короткий чек-лист перед выкладкой на прод

• Проверил, нужен ли XML-RPC хотя бы одному сервису.
• Выбрал способ блокировки: код, Nginx или IP-ограничение.
• Сделал бэкап конфига и файлов темы.
• Проверил /xmlrpc.php вручную.
• Проверил мобильное приложение и внешние интеграции, если они есть.
• Посмотрел логи после изменения.

Если нужен жёсткий и простой вариант — отключайте XML-RPC полностью. Если есть хотя бы один внешний клиент, лучше не рубить всё подряд, а ограничить доступ по IP или перенести интеграцию на REST API. В WordPress это почти всегда безопаснее, чем оставлять старый интерфейс открытым для всего интернета.