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

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

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

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

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

Сначала смотрят на реальные сценарии:

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

Как быстро диагностировать, нужен ли XML-RPC

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

Проверить наличие ответа можно и вручную:

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

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

Что отключать: файл, фильтр или правило на сервере

Есть три рабочих подхода. Они отличаются тем, насколько рано запрос будет отрезан и как легко потом отлаживать поведение.

Способ	Плюсы	Минусы	Когда выбирать
Фильтр в WordPress	Просто откатить, не требует правок сервера	Запрос доходит до WordPress	Если нужен быстрый и безопасный старт
Правило в Nginx/Apache	Отсекает запрос раньше, меньше нагрузки	Нужен доступ к конфигу сервера	Если сайт под атакой или нужен жёсткий запрет
Плагин безопасности	Удобно для админов без доступа к серверу	Зависимость от плагина, лишний слой	Если уже используете security-плагин

Для большинства проектов разумно начать с фильтра, а если атаки на xmlrpc.php заметны в логах — перенести блокировку на уровень веб-сервера.

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

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

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

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

Если нужно сохранить часть функциональности

Иногда задача не в полном отключении, а в том, чтобы убрать только pingback и trackback. Тогда лучше не рубить XML-RPC целиком, а отключить ненужные механизмы отдельно:

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

add_filter( 'pings_open', '__return_false' );

Это полезно, если сайт ещё принимает комментарии и вы хотите убрать только один из старых векторов спама.

Блокировка на уровне сервера

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

Nginx

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

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

Apache

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

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

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

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

• Откройте /xmlrpc.php в браузере или через curl — ожидается отказ в доступе или пустой ответ без полезной функциональности.
• Проверьте мобильное приложение WordPress, если оно используется.
• Проверьте интеграции публикации: автопостинг, внешние редакторы, Jetpack.
• Посмотрите логи сервера: запросы к xmlrpc.php должны либо исчезнуть, либо получать отказ до PHP.
• Убедитесь, что обычный вход в админку, REST API и публикация записей работают как раньше.

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

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

Если блокировка на сервере настроена правильно, вы увидите код отказа, а не полноценный ответ WordPress.

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

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

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

Поставили плагин безопасности и забыли, что он уже блокирует xmlrpc.php

Иногда админ добавляет ещё одно правило вручную и получает путаницу: в логах видно отказ, но непонятно, кто именно его отдаёт. В такой ситуации сначала проверьте, не дублируется ли блокировка в плагине, в .htaccess, в конфиге Nginx и в теме.

Заблокировали файл, но атаки в логах не исчезли

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

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

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

Что выбрать для постоянной настройки

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

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

Файл можно положить в wp-content/mu-plugins/disable-xmlrpc.php. Это удобнее, чем править тему, и прозрачнее, чем прятать логику в большом наборе функций.

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

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

• уберите неиспользуемые pingback/trackback;
• ограничьте попытки входа в админку;
• проверьте, не открыт ли /wp-login.php для массового брутфорса;
• обновите ядро, плагины и тему до актуальных версий;
• посмотрите, не создаёт ли лишнюю нагрузку REST API или сторонний плагин авторизации.

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

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