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

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

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

Если сайт не использует внешние клиенты для публикации, старые интеграции и pingback/trackback, XML-RPC чаще всего только расширяет поверхность атаки. Через него удобнее пробовать перебор паролей и отправлять лишние запросы к xmlrpc.php. Для обычного сайта, где публикация идёт только из админки WordPress, отключение обычно оправдано.

Но есть важная оговорка: отключать его нужно только после проверки, что он не нужен для:

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

Диагностика: как понять, используется ли XML-RPC сейчас

Начните не с блокировки, а с проверки логов и реальных сценариев. Если у вас есть доступ к access log веб-сервера, посмотрите, есть ли обращения к /xmlrpc.php. Если запросы идут регулярно, это уже сигнал, что кто-то или что-то его использует.

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

• Откройте https://ваш-домен/xmlrpc.php в браузере. Сам по себе ответ WordPress ещё не означает, что функция нужна, но показывает, что файл доступен.
• Проверьте, не подключён ли Jetpack или другой сервис, который может опираться на XML-RPC.
• Если сайт старый, найдите в коде темы и плагинов упоминания xmlrpc.php или функций вроде wp_remote_post() с внешними публикациями.

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

Способы отключения: что выбрать

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

Способ	Плюсы	Минусы	Когда выбирать
Плагин безопасности	Быстро, без правки файлов	Лишняя зависимость, не всегда прозрачно	Если нужен временный или управляемый вариант
Код в functions.php или mu-plugin	Контроль, легко откатить	Нужно аккуратно тестировать	Если есть доступ к теме или must-use плагинам
Правило на сервере	Режет запросы раньше WordPress	Зависит от конфигурации хостинга	Если нужен жёсткий запрет на уровне веб-сервера

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

Самый понятный способ — запретить доступ к xmlrpc.php через фильтр xmlrpc_enabled. Это не ломает сайт целиком и легко проверяется. Лучше добавлять такой код не в тему, а в небольшой mu-plugin, чтобы он не пропал при смене темы.

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

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

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

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

add_filter( 'wp_headers', function( $headers ) {
    if ( isset( $headers['X-Pingback'] ) ) {
        unset( $headers['X-Pingback'] );
    }
    return $headers;
} );

Этот вариант полезен, если вы хотите убрать лишние сигналы для сканеров и не оставлять pingback как «полуоткрытую» функцию.

Если нужен жёсткий запрет на уровне сервера

Когда сайт часто атакуют перебором через xmlrpc.php, разумно отрезать запросы раньше WordPress. Для Apache это можно сделать через .htaccess:

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

Для Nginx правило обычно добавляют в конфигурацию сайта:

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

Такой способ эффективнее, потому что WordPress даже не стартует на этих запросах. Но он подходит только если вы уверены, что XML-RPC не нужен ни одному сервису.

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

После отключения важно не ограничиться «ошибок в админке нет». Проверьте несколько конкретных сценариев:

• откройте /xmlrpc.php напрямую — должен быть отказ в доступе или пустой ответ в зависимости от способа блокировки;
• попробуйте опубликовать запись из внешнего клиента, если он у вас был подключён;
• посмотрите access log: запросы к xmlrpc.php должны либо исчезнуть, либо получать отказ;
• проверьте, не появились ли ошибки у Jetpack или других интеграций;
• убедитесь, что обычная публикация из админки работает как раньше.

Если вы используете мониторинг или WAF, полезно отдельно посмотреть, не выросло ли число 403/404 по этому адресу. Это поможет понять, не продолжают ли сканеры стучаться в закрытую точку.

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

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

Значит, зависимость не была учтена. Верните доступ, проверьте, какой именно сервис отправляет запросы, и решите, можно ли заменить его REST API или другим способом интеграции. Не отключайте всё «вслепую» на продакшене.

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

На Nginx .htaccess не используется. Если сайт на Nginx, правило нужно добавлять в конфигурацию виртуального хоста. На Apache проверьте, что модуль mod_authz_core включён и что файл действительно читается сервером.

Сайт продолжает получать много запросов к xmlrpc.php

Это нормально для публичного сайта, который уже попал в списки сканирования. Блокировка не убирает попытки, а только делает их бесполезными. Если запросов очень много, дополнительно смотрите на WAF, rate limiting и ограничения на уровне хостинга.

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

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

Что ещё стоит сделать для безопасности

Отключение XML-RPC — не замена нормальной защите входа. Если у вас слабые пароли, нет двухфакторной аутентификации и открыт /wp-login.php для перебора, проблему это не решит. Минимальный набор после отключения XML-RPC:

• сильные пароли и уникальные учётные записи;
• ограничение попыток входа или защита на уровне WAF;
• 2FA для администраторов;
• регулярные обновления ядра, тем и плагинов;
• проверка логов на повторяющиеся атаки.

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

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