Как отключить XML-RPC в WordPress и не сломать удалённый доступ

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

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

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

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

• публикуете записи через старые мобильные клиенты WordPress;
• используете Jetpack и отдельные его функции, завязанные на удалённое подключение;
• подключаете внешние сервисы, которые работают через XML-RPC, а не через REST API;
• используете pingback/trackback и понимаете, зачем они вам нужны.

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

Диагностика: как понять, что XML-RPC открыт

Самый простой тест — открыть файл /xmlrpc.php в браузере или запросить его через curl. Если файл доступен, это ещё не значит, что он уязвим, но значит, что интерфейс активен.

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

Обычно в ответе вы увидите статус вроде 405 Method Not Allowed на GET-запрос, либо другой ответ, который подтверждает наличие файла. Для более точной проверки можно отправить тестовый XML-RPC-запрос, но для повседневной диагностики достаточно понять, не отдаёт ли сайт этот endpoint вообще.

Если у вас есть доступ к логам веб-сервера, обратите внимание на частые обращения к xmlrpc.php и повторяющиеся POST-запросы с одинаковым User-Agent. Это типичный признак автоматизированного перебора.

Как отключить XML-RPC: три рабочих подхода

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

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

Если нужен простой и понятный способ, добавьте фильтр xmlrpc_enabled. Лучше делать это в mu-plugins или в небольшом собственном плагине, а не в functions.php активной темы. Тогда отключение не пропадёт после смены темы.

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

Если вам нужно не просто выключить XML-RPC, а ещё и убрать pingback-методы, можно дополнительно отфильтровать методы:

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

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

Вариант 2: блокировка на уровне сервера

Если цель — не грузить PHP вообще, блокируйте доступ к xmlrpc.php на веб-сервере. Это особенно полезно на сайтах, где боты регулярно стучатся в этот файл.

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

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

Для Nginx обычно добавляют отдельный location:

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

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

Вариант 3: отключение через плагин

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

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

Пошаговое решение без лишних рисков

1. Проверьте, использует ли сайт Jetpack, внешнюю публикацию или старые мобильные клиенты.
2. Сделайте резервную копию конфигурации и файлов, если правите сервер.
3. Выберите один способ отключения: код, сервер или плагин.
4. Внесите изменение только в одном месте, не смешивайте сразу несколько методов.
5. Проверьте доступ к /xmlrpc.php и работу нужных интеграций.
6. Посмотрите логи на предмет ошибок и повторных попыток доступа.

Если вы не уверены, начните с кодового варианта. Его проще откатить, и он не требует доступа к конфигу веб-сервера. Если же у вас заметная нагрузка от ботов, серверная блокировка обычно эффективнее.

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

Проверка должна быть не только визуальной. Откройте https://example.com/xmlrpc.php и убедитесь, что endpoint больше не отвечает как рабочий интерфейс. Затем проверьте, не сломались ли нужные сценарии.

• Если вы отключали через код, убедитесь, что фильтр реально загружается: временно добавьте логирование или проверьте, что файл с кодом активен.
• Если блокировали на сервере, запрос к xmlrpc.php должен отдаваться без участия WordPress.
• Если использовали плагин, проверьте, что его настройка не сбросилась после обновления.

Полезно также сделать тестовый POST-запрос с заведомо неверным XML-RPC payload и посмотреть, что сервер не пропускает его дальше. Если у вас есть доступ к access log, после изменения должно стать меньше обращений к этому файлу, а в error log не должно появиться новых ошибок, связанных с правилами доступа.

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

Отключили XML-RPC, но Jetpack перестал подключаться

Это ожидаемо, если вы используете функции Jetpack, которые завязаны на XML-RPC. Решение простое: либо вернуть XML-RPC, либо отказаться от конкретной интеграции и заменить её REST API-решением, если это возможно.

Добавили правило в .htaccess, но оно не работает

Частая причина — сайт работает не на Apache, а на Nginx, либо .htaccess вообще не читается на текущем хостинге. В этом случае правило нужно переносить в конфиг сервера. Ещё одна ошибка — правило стоит ниже других директив, которые уже отдают файл раньше.

Использовали несколько способов сразу

Например, отключили XML-RPC через код, а потом ещё и через security-плагин. В результате сложно понять, что именно сломало интеграцию. Для диагностики оставляйте один механизм. Если нужен второй как запасной, документируйте это отдельно.

Сломали trackback/pingback, не понимая последствий

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

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

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

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

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

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

В итоге рабочая схема простая: сначала выясняете, нужен ли XML-RPC, потом выбираете один способ отключения, после этого проверяете endpoint и реальные интеграции. Такой подход даёт предсказуемый результат и не превращает безопасность в набор случайных правок.