Как отключить XML-RPC в WordPress и проверить, что сайт не ломается

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

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

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

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

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

Сначала проверьте, есть ли реальные зависимости. Не ориентируйтесь только на «кажется, не используется».

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

Если после этого остаются сомнения, лучше сначала ограничить доступ, а не рубить всё сразу.

Как отключить XML-RPC в WordPress без плагина

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

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

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

Вариант через mu-plugin

Создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, её можно создать вручную.

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

Плюс этого подхода в том, что код не исчезнет после смены темы и не зависит от активного плагинного набора.

Если нужен не полный запрет, а ограничение доступа

Иногда XML-RPC нужен только для одного сервиса, а остальные обращения вы хотите отсечь на уровне сервера. В этом случае можно закрыть файл xmlrpc.php через веб-сервер. Это полезно, если атаки идут массово и вы хотите отрезать их до PHP.

Apache: блокировка через .htaccess

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

Этот вариант работает только если сайт обслуживается Apache или совместимым сервером с поддержкой .htaccess. На Nginx такой блок не сработает.

Nginx: запрет на уровне конфигурации

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

После изменения конфигурации Nginx не забудьте проверить синтаксис и перезагрузить сервис. На боевом сайте это лучше делать в окно низкой нагрузки.

Сравнение подходов: код, сервер, плагин

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

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

После отключения не ограничивайтесь тем, что страница /xmlrpc.php «как-то изменилась». Проверьте несколько сценариев.

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

Для более точной проверки можно отправить тестовый запрос вручную. Если XML-RPC отключён, сервер не должен принимать метод system.listMethods как рабочий вызов.

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

Если вы блокировали файл на уровне Nginx или Apache, в ответе обычно будет отказ от сервера. Если отключали через WordPress, поведение зависит от конфигурации и кода, но успешного XML-RPC-ответа быть не должно.

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

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

Это типичная ситуация. Не все установки Jetpack одинаково зависят от XML-RPC, но часть функций может использовать удалённое соединение. Если Jetpack нужен, сначала проверьте документацию и сценарий использования, а уже потом режьте доступ на сервере.

Добавили код в родительскую тему

После обновления темы правка исчезнет. Для таких изменений используйте дочернюю тему или mu-plugin. Это особенно важно, если вы обслуживаете клиентский сайт и не хотите ловить «почему всё снова включилось» после апдейта.

Закрыли xmlrpc.php, но атаки в логах остались

Это нормально: сканеры продолжают стучаться по старому адресу. Важен не сам факт обращения, а то, что запросы не доходят до WordPress и не расходуют ресурсы PHP.

Сломали публикацию из внешнего сервиса

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

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

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

• Не отключайте XML-RPC «наугад» на сайте, где есть внешние интеграции.
• Если нужен только один сервис, лучше ограничить доступ на уровне сервера, чем держать интерфейс открытым для всех.
• После правки проверьте не только фронтенд, но и админку, REST API и подключённые сервисы.
• Если на сайте много мусорных обращений к xmlrpc.php, посмотрите логи и правила WAF, а не только WordPress-код.

Если вам нужно одновременно чистить сайт от лишних дублей, мусорных мета-тегов и части SEO-шума, иногда удобнее решать это отдельным инструментом вроде Clearfy Pro, но для XML-RPC я бы всё равно предпочёл точечную настройку, а не «комбайн ради одной галочки».

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