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

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

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

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

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

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

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

Сначала посмотрите, есть ли обращения к xmlrpc.php в логах веб-сервера или в журнале безопасности. Если у вас включён доступ к access log, такие запросы легко найти по имени файла. Если запросы идут регулярно и не похожи на ваши собственные, это уже аргумент в пользу отключения.

Дополнительно проверьте, не используется ли XML-RPC в подключённых сервисах. Типичные признаки:

• мобильное приложение WordPress публикует записи;
• внешний редактор или CMS забирает и отправляет контент через XML-RPC;
• есть старые интеграции с Jetpack или похожими сервисами, завязанные на удалённые вызовы;
• в логах встречаются методы pingback.ping, metaWeblog.newPost, wp.getUsersBlogs.

Если вы не уверены, временно ограничьте доступ к xmlrpc.php на уровне сервера только для своих IP или тестовой среды и посмотрите, не появятся ли ошибки в рабочих сценариях.

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

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

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

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

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

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

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

Вариант 2. Блокировка на уровне сервера

Если у вас большой поток мусорных запросов, лучше отрезать их раньше, чем они дойдут до PHP. Для nginx это обычно делается отдельным правилом в конфиге сайта:

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

Для Apache можно использовать правило в .htaccess или конфиге виртуального хоста:

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

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

Вариант 3. Плагин безопасности

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

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

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

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

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

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

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

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

Что смотреть в ответе:

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

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

Проверка рабочих интеграций

Не ограничивайтесь только проверкой URL. Обязательно протестируйте реальные сценарии:

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

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

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

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

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

Спрятали проблему плагином, но не убрали источник нагрузки

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

Внесли правило в тему, а потом потеряли его после обновления

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

Заблокировали XML-RPC, но не проверили логи

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

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

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

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

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

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

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