Как отключить XML-RPC в WordPress без поломки интеграций и защиты от брутфорса

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

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

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

Если сайт не использует внешние клиенты, старые мобильные приложения, публикацию по удалённому API и сервисы, которым нужен xmlrpc.php, этот интерфейс обычно можно убрать. Для большинства обычных сайтов он не даёт пользы, но остаётся отдельной точкой входа, которую часто пытаются атаковать перебором паролей и запросами к методу system.multicall.

Но отключать его стоит не «по моде», а после проверки зависимостей. Особенно если сайт:

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

Диагностика: как понять, используется ли xmlrpc.php

Самый надёжный путь — посмотреть логи доступа и список интеграций. Если у вас есть доступ к серверу, проверьте, обращается ли кто-то к /xmlrpc.php. В логах это видно сразу, особенно если есть повторяющиеся POST-запросы.

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

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

старые приложения WordPress для iOS/Android;
сервисы автопостинга;
инструменты массовой публикации;
некоторые плагины для удалённой работы с контентом.

Ещё один быстрый тест — открыть https://ваш-домен/xmlrpc.php в браузере. Если интерфейс доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не доказывает, что он нужен, но подтверждает, что endpoint активен.

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

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

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

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

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

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

Это отключает сам XML-RPC endpoint на уровне WordPress. Для большинства сайтов этого достаточно.

Вариант 2: запретить доступ к 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;
}

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

Вариант 3: оставить XML-RPC, но ограничить риск

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

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

Пошаговое решение без сюрпризов

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

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

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

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

Если вы отключали через фильтр, можно проверить и через PHP:

<?php
if ( function_exists( 'xmlrpc_enabled' ) ) {
    var_dump( xmlrpc_enabled() );
}

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

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

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

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

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

Причина простая: сервис или приложение использовало xmlrpc.php напрямую. Решение — вернуть endpoint и перевести интеграцию на REST API, если это возможно, либо оставить XML-RPC включённым и ограничить доступ.

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

На Nginx файл .htaccess не используется. Если сайт работает на Nginx, правило нужно добавлять в конфиг сервера. И наоборот: для Apache серверные директивы Nginx не помогут.

Отключили в теме, а после обновления всё вернулось

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

Поставили тяжёлый security-плагин только ради одной функции

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

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

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

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

Отдельно проверьте:

сложность паролей у администраторов;
наличие двухфакторной аутентификации, если она доступна;
ограничение попыток входа;
актуальность ядра, темы и плагинов;
логи на повторяющиеся POST-запросы к xmlrpc.php.

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