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

Автор: Артем Никитин | Опубликовано: 11.09.2026

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

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

Когда XML-RPC реально нужен, а когда его можно закрыть

Сначала проверьте не абстрактную «рекомендацию из интернета», а свои реальные сценарии. XML-RPC нужен, если у вас есть:

старые внешние клиенты для публикации записей;
мобильное приложение WordPress, которое работает через XML-RPC;
интеграции, завязанные на xmlrpc.php для удалённой публикации или pingback;
наследуемые скрипты, которые отправляют запросы методом system.multicall.

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

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

На Apache и Nginx можно найти обращения к XML-RPC по access-log. Пример для Linux-сервера:

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

Если видите много запросов с кодами 200, 403 или повторяющиеся POST-запросы с одного и того же IP, это уже повод ограничить доступ. Отдельно проверьте, не завязаны ли на XML-RPC ваши интеграции — например, сторонние сервисы публикации или старые плагины синхронизации.

Как отключить XML-RPC в WordPress кодом

Самый прозрачный способ — отключить XML-RPC через фильтр. Это удобно, если вы контролируете тему или используете небольшой mu-plugin. Добавьте код в functions.php дочерней темы или в отдельный must-use plugin.

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

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

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

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

add_action( 'init', function () {
    if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
        status_header( 403 );
        exit;
    }
} );

На практике чаще хватает первого варианта. Второй имеет смысл, если вы хотите явно закрыть запросы и видеть в логах отказ, а не просто пустой ответ.

Как ограничить доступ к xmlrpc.php на уровне сервера

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

Nginx

Для Nginx обычно добавляют отдельное правило в конфигурацию сайта:

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

После правки проверьте конфигурацию и перезагрузите Nginx. Такой вариант полностью блокирует доступ к файлу, не давая WordPress даже стартовать.

Apache

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

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

Если у вас старый стек с Apache 2.2, синтаксис будет другим, но на современных хостингах уже обычно используется Require all denied.

Что выбрать: код WordPress, сервер или плагин

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

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

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

После отключения не ограничивайтесь «страница открылась — значит всё ок». Проверьте именно тот сценарий, который вы закрывали.

Откройте /xmlrpc.php в браузере или через curl.
Убедитесь, что POST-запросы больше не проходят.
Посмотрите access-log: обращения к xmlrpc.php должны либо исчезнуть, либо получать отказ.
Проверьте, не сломались ли внешние публикации или мобильное приложение, если вы ими пользуетесь.

Пример проверки через curl:

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

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

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

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

Значит, этот канал вам всё-таки нужен. Не пытайтесь лечить это «половинчатым» отключением. Верните доступ и вместо полного запрета ограничьте его по IP, если у вас есть фиксированные адреса, или закройте только лишние методы на уровне сервера и WAF.

Закрыли файл, но атаки продолжаются в логах

Это нормально: боты продолжают стучаться, но уже получают отказ. Если нагрузка всё равно заметна, добавьте блокировку на уровне CDN, firewall или fail2ban по повторяющимся запросам к /xmlrpc.php.

Сломали доступ к сайту через неверное правило в .htaccess

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

Отключили XML-RPC, но забыли про pingback

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

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

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

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

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

В итоге правильный подход здесь не «отключить всё подряд», а убрать именно тот канал, который вам не нужен, и проверить это по логам и реальному поведению сайта. Тогда решение будет и безопасным, и предсказуемым.