Как отключить XML-RPC в WordPress и не сломать внешние интеграции

XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, старые клиенты публикации, внешние сервисы или часть автоматизаций. Проблема не в самом факте отключения, а в том, что перед этим не проверяют, кто именно ходит в /xmlrpc.php.

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

Когда XML-RPC действительно можно отключать

В типичном современном сайте XML-RPC не нужен, если вы:

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

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

Диагностика: кто реально обращается к xmlrpc.php

Первый шаг — посмотреть серверные логи. Ищите запросы к /xmlrpc.php за последние дни или недели. Если у вас Nginx, это можно сделать по access log. На Apache логика та же: важны не команды, а сам факт повторяющихся обращений с понятными User-Agent и IP.

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

Если логов много, полезно сгруппировать запросы по IP:

grep 'xmlrpc.php' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

Дальше проверьте, не использует ли сайт сервисы, которые завязаны на XML-RPC. Частые кандидаты:

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

Если сомневаетесь, временно не блокируйте endpoint полностью, а сначала ограничьте доступ по IP или посмотрите, какие запросы идут в течение нескольких дней. Это безопаснее, чем сразу ставить жесткий запрет.

Пошаговое решение: как отключить XML-RPC без лишнего риска

Вариант 1. Отключение через код

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

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

Это отключает сам XML-RPC на уровне WordPress. Запросы к /xmlrpc.php будут получать отказ, а не обрабатываться системой.

Если хотите не просто отключить функциональность, а явно вернуть 403 на уровне WordPress, можно добавить проверку в init:

<?php
add_action( 'init', function () {
    if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
        wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
    }
} );

На практике первый вариант обычно проще и чище. Второй полезен, если вам нужно явно фиксировать отказ в логах или поведение на уровне приложения.

Вариант 2. Ограничение на уровне веб-сервера

Если вы хотите отрезать endpoint раньше, чем WordPress начнет загружаться, используйте правила веб-сервера. Это снижает нагрузку и уменьшает шум от сканеров.

Для Nginx:

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

Для Apache в .htaccess можно использовать:

<Files xmlrpc.php>
    Require all denied
</Files>

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

Вариант 3. Плагин для точечной блокировки

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

Как проверить, что решение сработало

После внедрения откройте /xmlrpc.php в браузере или отправьте тестовый запрос. Если блокировка настроена правильно, вы не должны получить обычный ответ XML-RPC.

Проверка через curl:

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

Ожидаемое поведение зависит от способа блокировки:

• при отключении через WordPress — ошибка или отказ в обработке;
• при блокировке на сервере — 403 Forbidden;
• при жестком deny — запрос не должен доходить до WordPress.

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

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

Отключили XML-RPC, но забыли про Jetpack или старый клиент

Если после блокировки перестали работать уведомления, публикация или синхронизация, значит зависимость была реальной. Решение — не «включить всё обратно», а понять, какой именно сценарий использует endpoint, и заменить его на REST API или другой способ интеграции.

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

Жесткий deny удобен, но он скрывает детали. Если вам нужно расследовать атаки или понять, кто обращается к endpoint, временно оставьте логирование включенным. Иначе вы увидите только факт блокировки, без контекста.

Отключили XML-RPC в плагине безопасности и забыли, где это сделано

Такой вариант часто ломает поддержку: через полгода никто не помнит, что именно отключало endpoint. Лучше фиксировать изменения в конфигурации проекта или в репозитории, чем держать их в интерфейсе плагина без документации.

Смешали отключение XML-RPC с отключением REST API

Это разные механизмы. REST API нужен многим современным плагинам, редактору блоков и внешним интеграциям. Если вы отключаете оба интерфейса без анализа, рискуете сломать гораздо больше, чем планировали.

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

Отключение XML-RPC — не панацея. Если цель в снижении шума от атак, полезно дополнительно:

• ограничить частоту запросов на уровне WAF или сервера;
• проверить, не открыт ли лишний доступ к wp-login.php;
• обновить ядро, темы и плагины;
• убрать неиспользуемые плагины и темы;
• настроить нормальные резервные копии перед изменениями.

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

Практический чек-лист перед отключением

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

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