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

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

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

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

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

• подозрительные POST-запросы к /xmlrpc.php в логах;
• попытки брутфорса через метод system.multicall;
• лишние обращения от мониторинга безопасности;
• ошибки в WAF или на хостинге из-за массовых запросов к XML-RPC;
• отсутствие реальной необходимости в публикации через внешние клиенты.

Если у вас есть Jetpack, мобильное приложение WordPress, старые интеграции с внешними сервисами или публикация через сторонний софт, сначала проверьте, не завязаны ли они на XML-RPC. Иначе можно получить не «усиление безопасности», а поломку рабочего сценария.

Диагностика: нужен ли XML-RPC именно вашему сайту

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

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

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

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

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

Это не доказывает, что XML-RPC нужен, но помогает понять, доступен ли файл вообще. Для более точной проверки можно отправить тестовый POST-запрос, однако на боевом сайте лучше не экспериментировать без понимания, что именно будет обработано.

Как отключить XML-RPC: сравнение подходов

Есть три практических варианта: код в functions.php или mu-plugin, плагин безопасности и блокировка на уровне сервера. У каждого свой компромисс.

Для большинства сайтов с доступом к коду лучший вариант — mu-plugin. Он не зависит от темы и не исчезнет после обновления шаблона.

Пошаговое решение через код

Если XML-RPC не нужен, можно отключить его фильтром xmlrpc_enabled. Это корректный и проверяемый способ для WordPress.

<?php
/**
 * Disable XML-RPC.
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Код можно положить в functions.php дочерней темы, но надёжнее — в отдельный mu-plugin. Тогда он не потеряется при смене темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

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

<?php
add_action( 'init', function () {
    if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
        status_header( 403 );
        exit;
    }
} );

Этот приём не заменяет полноценную серверную блокировку, но помогает закрыть доступ на уровне WordPress, если хостинг не даёт настроить правила веб-сервера.

Отключение через плагин: когда это уместно

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

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

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

После отключения важно не ограничиться «в админке всё открывается». Проверка должна показать, что XML-RPC реально перестал отвечать и при этом не пострадали нужные интеграции.

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

• открыть /xmlrpc.php в браузере — должен быть нерабочий ответ, а не обычная точка входа WordPress;
• посмотреть логи веб-сервера на наличие обращений к этому файлу;
• проверить публикацию из тех сервисов, которые вы считали зависимыми;
• убедиться, что вход в админку, REST API и обычные формы работают как раньше.

Если у вас есть доступ к командной строке, можно ещё раз проверить заголовки ответа:

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

Для более строгой проверки полезно сравнить ответ до и после изменения. До отключения WordPress обычно отвечает иначе, чем после фильтра xmlrpc_enabled или серверной блокировки.

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

Отключили XML-RPC, а потом перестал работать Jetpack

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

Сделали правку в теме, а после обновления всё вернулось

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

Поставили плагин, но xmlrpc.php всё ещё отвечает

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

Сломали мобильную публикацию и не заметили сразу

Проблема всплывает позже, когда кто-то пытается опубликовать запись из внешнего клиента. Поэтому перед отключением стоит составить короткий чек-лист зависимостей и проверить его на тестовом сайте или в staging-окружении.

Чек-лист перед отключением

• Проверены логи на реальные обращения к xmlrpc.php.
• Нет активных интеграций, которым нужен XML-RPC.
• Есть резервный способ публикации или синхронизации.
• Изменение вынесено в mu-plugin или другой устойчивый слой.
• После правки выполнена ручная проверка ответа /xmlrpc.php.
• Тестированы вход в админку, REST API и критичные формы.

Что делать, если XML-RPC нужен, но его атакуют

Иногда отключать интерфейс нельзя, но оставить его без защиты тоже плохая идея. В таком случае лучше не ломать функциональность, а ограничить поверхность атаки: включить rate limiting на уровне WAF, закрыть доступ по IP для внутренних интеграций, обновить пароли и убрать устаревшие способы авторизации.

Если у вас есть контроль над сервером, можно дополнительно фильтровать запросы к xmlrpc.php до WordPress. Это особенно полезно, когда атаки идут массово и вы не хотите тратить ресурсы PHP на обработку мусора.

Для сайтов, где важна общая техническая чистота, удобно держать под рукой инструменты, которые помогают убирать лишние технические хвосты и дубли настроек. Например, Clearfy Pro от WPShop часто используют именно для такой рутинной оптимизации, но сам XML-RPC всё равно лучше отключать точечно и с проверкой зависимостей: https://wpshop.ru/plugins/clearfy.

Главная мысль простая: XML-RPC не нужно отключать «по моде». Сначала проверьте, кто им пользуется, потом выберите способ отключения и только после этого закрывайте доступ. Так вы уберёте лишний риск, но не сломаете рабочие сценарии.