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

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

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

Когда XML-RPC реально мешает

Если в логах много запросов к /xmlrpc.php, это не всегда проблема само по себе. Проблема начинается, когда:

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

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

Быстрая диагностика

Сначала посмотрите, обращается ли кто-то к xmlrpc.php. Если есть доступ к логам веб-сервера, ищите строки с этим путём. Если логов нет, можно временно проверить ответ напрямую:

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

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

Как отключить XML-RPC: варианты и компромиссы

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

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

Самый предсказуемый способ — добавить фильтр в mu-plugins или в дочернюю тему. Для большинства случаев достаточно такого кода:

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

Если хотите не просто отключить XML-RPC, а ещё и отдавать 403 на прямой запрос к xmlrpc.php, можно добавить отдельную проверку в mu-plugin:

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

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

Этот вариант не ломает обычную работу сайта, но блокирует сам механизм XML-RPC на уровне WordPress.

Вариант 2: отключение через сервер

Если у вас nginx, можно закрыть доступ к файлу ещё до загрузки WordPress. Это полезно, когда сайт получает много мусорных запросов и вы хотите сэкономить ресурсы.

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

Для Apache обычно используют правила в .htaccess:

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

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

Что проверить после отключения

После внедрения решения важно не ограничиться “ошибок в админке нет”. Проверьте конкретные сценарии, которые чаще всего завязаны на XML-RPC.

• Откройте https://example.com/xmlrpc.php в браузере или через curl и убедитесь, что доступ закрыт.
• Попробуйте опубликовать запись из мобильного приложения WordPress, если вы им пользуетесь.
• Проверьте Jetpack, если он установлен: часть функций может работать иначе без XML-RPC.
• Посмотрите логи сервера и убедитесь, что поток запросов к xmlrpc.php прекратился или стал блокироваться на уровне сервера.

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

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

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

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

Поставили плагин, но запросы всё равно идут

Так бывает, если плагин только отключает функциональность внутри WordPress, но не режет запросы на уровне сервера. В этом случае боты всё равно будут стучаться в файл, просто получат ответ от WordPress. Для снижения нагрузки лучше добавить правило в nginx или Apache.

Закрыли доступ в .htaccess, а сайт на nginx

.htaccess не работает на nginx. Если сервер не Apache, правило нужно переносить в конфиг nginx или использовать отключение через WordPress-хук.

Сломали Jetpack и не поняли почему

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

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

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

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

Признаки корректной настройки довольно конкретные:

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

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

Практические советы по безопасности и производительности

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

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

Если сайт работает на высоком трафике, серверное блокирование XML-RPC обычно предпочтительнее: оно уменьшает количество лишних PHP-запусков. Но если доступ к конфигу ограничен, фильтр xmlrpc_enabled — нормальный и безопасный старт.

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