Как отключить XML-RPC и вернуть 403 на запросы к xmlrpc.php в WordPress

Автор: Евгения Мельникова | Опубликовано: 30.09.2026

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

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

Когда проблема действительно в xmlrpc.php

Сначала стоит убедиться, что речь именно об XML-RPC, а не о другом источнике нагрузки. Типичный признак — в access log много обращений к /xmlrpc.php с одинаковых или меняющихся IP, часто с методами POST. В WordPress это может выглядеть как:

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

Если у вас уже есть защита на уровне WAF, проверьте, не блокирует ли она только часть запросов. Иногда сайт «защищён», но xmlrpc.php всё равно отвечает 200 и продолжает быть точкой входа для перебора.

Как быстро проверить, что XML-RPC вообще доступен

Самый простой тест — отправить запрос к файлу и посмотреть код ответа. Это можно сделать из терминала:

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

Для полноценной проверки лучше отправить POST-запрос с заведомо пустым телом и посмотреть, как сервер отвечает на сам факт обращения:

curl -s -o /dev/null -D - -X POST https://example.com/xmlrpc.php

Если XML-RPC ещё активен, вы обычно увидите не 403, а другой ответ, зависящий от конфигурации сервера и WordPress.

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

Есть три рабочих подхода. У каждого свой компромисс: плагин проще, код гибче, серверный запрет надёжнее. Для технической статьи важен не «самый правильный» вариант, а тот, который соответствует вашей инфраструктуре.

Подход	Плюсы	Минусы	Когда использовать
Плагин безопасности	Быстро, без правок сервера	Зависимость от плагина, лишняя нагрузка	Если нужен быстрый запуск без доступа к конфигам
Код в теме или MU-plugin	Контроль, минимум лишнего	Нужно аккуратно поддерживать	Если есть доступ к файлам сайта и нужен точечный контроль
.htaccess / nginx	Блокировка до загрузки WordPress	Зависит от веб-сервера	Если нужно жёстко закрыть точку входа

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

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

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

Вариант 1: отключить XML-RPC через фильтр

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

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

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

Вариант 2: принудительно отдавать 403 на xmlrpc.php

Если вам нужен именно код ответа 403, можно перехватить запрос раньше и завершить его с нужным статусом. Для этого удобно использовать init и проверку $_SERVER['REQUEST_URI']:

<?php
add_action( 'init', function () {
    if ( isset( $_SERVER['REQUEST_URI'] ) && strpos( $_SERVER['REQUEST_URI'], '/xmlrpc.php' ) !== false ) {
        status_header( 403 );
        nocache_headers();
        exit;
    }
}, 1 );

Этот вариант практичнее, если вам важно, чтобы сканеры и боты видели именно запрет, а не просто пустой ответ. Но если сервер уже отдаёт 403 на уровне nginx или Apache, дублировать логику в WordPress не обязательно.

Вариант 3: MU-plugin для стабильности

Если вы не хотите привязываться к теме, создайте файл wp-content/mu-plugins/disable-xmlrpc.php. MU-plugin загружается автоматически и не зависит от активной темы:

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );
add_action( 'init', function () {
    if ( isset( $_SERVER['REQUEST_URI'] ) && strpos( $_SERVER['REQUEST_URI'], '/xmlrpc.php' ) !== false ) {
        status_header( 403 );
        nocache_headers();
        exit;
    }
}, 1 );

Такой вариант удобен, если у вас несколько сайтов и нужна одинаковая политика блокировки.

Серверный запрет: когда он лучше кода

Если есть доступ к конфигу веб-сервера, блокировка на этом уровне надёжнее. Запрос не доходит до PHP, а значит, не тратит ресурсы WordPress.

Apache: правило для .htaccess

Для Apache можно добавить отдельное правило в .htaccess:

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

Это простой и понятный вариант. Он закрывает файл напрямую, и WordPress уже не участвует в обработке.

nginx: возврат 403

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

location = /xmlrpc.php {
    deny all;
    return 403;
}

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

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

Проверка должна быть не «на глаз», а по факту ответа сервера. Смотрите на три вещи: код ответа, содержимое тела и отсутствие лишних ошибок в логах.

выполните curl -I https://example.com/xmlrpc.php;
проверьте POST-запрос через curl -s -o /dev/null -D - -X POST https://example.com/xmlrpc.php;
убедитесь, что в access log запросы к xmlrpc.php больше не доходят до PHP, если блокировка серверная;
проверьте внешние сервисы, которые могли использовать XML-RPC;
посмотрите, не появились ли новые ошибки в логах после изменения.

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

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

Отключили XML-RPC, но 403 не появился

Это нормально для фильтра xmlrpc_enabled: он отключает функциональность, но не всегда меняет код ответа. Если нужен именно 403, добавьте серверное правило или перехват запроса на уровне WordPress.

Сломался мобильный клиент или внешняя публикация

Значит, где-то использовался XML-RPC. Перед блокировкой проверьте, какие сервисы подключены к сайту: старые приложения WordPress, автопостинг, интеграции с редакторами, некоторые сервисы мониторинга. Если такой сценарий нужен, не закрывайте XML-RPC полностью, а ограничьте доступ по IP или через WAF.

Правило в .htaccess не сработало

Частая причина — сайт работает не на Apache, а на nginx, либо .htaccess переопределяется другими правилами. В этом случае ищите конфигурацию виртуального хоста или используйте блокировку через WordPress.

Появились ошибки 500 после правки кода

Обычно это синтаксическая ошибка или вставка кода не в тот файл. Проверьте, что вы не добавили лишний <?php в уже открытый PHP-файл, и что код лежит в дочерней теме или MU-plugin, а не в файле, который перезаписывается обновлением.

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

Отключение XML-RPC полезно, но не решает все проблемы безопасности. Если цель — уменьшить поверхность атаки, посмотрите на соседние точки входа: /wp-login.php, REST API, устаревшие плагины, открытые архивы и лишние публичные эндпоинты.

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

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

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