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

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

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

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

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

Сценарии, где XML-RPC обычно не нужен

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

Если хотя бы один пункт под вопросом, сначала проверьте фактические обращения к xmlrpc.php. Иначе можно отключить то, что нужно рабочему процессу или интеграции.

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

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

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

Если логов много, полезно посмотреть не только факт обращений, но и источник. Частые запросы с разных IP, особенно с ошибками авторизации, — типичный признак перебора.

Ещё один практический тест — временно ограничить доступ к /xmlrpc.php и проверить, не сломались ли внешние сервисы. Но делать это лучше после короткой инвентаризации: какие плагины стоят, есть ли интеграции с публикацией, подключён ли Jetpack.

Что проверить перед отключением

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

Как отключить XML-RPC: рабочие способы

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

Способ 1: отключить XML-RPC через код

Самый простой вариант — добавить фильтр в functions.php дочерней темы или, что лучше, в небольшой MU-плагин. Так вы не потеряете настройку при смене темы.

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

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

Способ 2: заблокировать доступ на уровне Nginx

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

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

После изменения конфигурации не забудьте проверить синтаксис и перезагрузить Nginx. Это уже серверная операция, и она должна быть сделана аккуратно.

Способ 3: ограничить через Apache

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

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

Важно: если хостинг использует старую версию Apache или нестандартную схему прав доступа, правило нужно протестировать отдельно. Не стоит предполагать, что оно сработает «как в примере» без проверки.

Пошаговое решение без лишнего риска

Если нужен безопасный порядок действий, делайте так:

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

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

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

Проверка должна быть не «на глаз», а по факту ответа сервера. Самый простой тест — открыть /xmlrpc.php в браузере или через curl. В норме вы должны получить отказ или пустой ответ, а не рабочую страницу XML-RPC.

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

Если вы отключали через фильтр WordPress, запрос может вернуть 403, 405 или другой отказ в зависимости от способа блокировки. Если вы видите обычный ответ WordPress с сообщением о том, что XML-RPC сервер принимает только POST-запросы, значит интерфейс всё ещё доступен.

Дополнительно проверьте:

• нет ли ошибок в логах после отключения;
• не перестали ли работать внешние публикации;
• не появились ли жалобы от редакторов или интеграций;
• не выросло ли число 404/403 на xmlrpc.php в access log.

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

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

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

Закрыли xmlrpc.php, но забыли про Jetpack

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

Сделали блокировку на сервере, но не проверили кэш и прокси

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

Сломали интеграцию, не посмотрев логи

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

Безопасность и производительность: что ещё имеет смысл сделать

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

На практике полезно сочетать это с другими мерами:

• ограничить попытки входа в админку;
• включить двухфакторную аутентификацию для администраторов;
• проверить, не открыт ли доступ к wp-login.php для массового перебора;
• убрать неиспользуемые плагины и темы;
• следить за обновлениями ядра WordPress и плагинов.

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

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