Как отключить XML-RPC в WordPress и вернуть 403 для лишних запросов

Автор: Егор Смирнов | Опубликовано: 17.08.2026

Если цель — не просто «выключить XML-RPC», а именно убрать лишний вход для ботов и старых интеграций, важно понимать разницу между блокировкой на уровне WordPress и блокировкой на уровне веб-сервера. Первый вариант часто оставляет 200 OK с пустым ответом или 405, второй даёт более жёсткий и предсказуемый 403 Forbidden. Для безопасности это обычно лучше: запросы не доходят до PHP, а нагрузка на сайт ниже.

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

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

Чаще всего этот файл атакуют перебором логинов, pingback-запросами и шумными сканерами. На небольшом сайте это может быть незаметно, но на VPS с ограниченными ресурсами лишние обращения быстро превращаются в лишние PHP-процессы. Если в логах вы видите регулярные запросы к xmlrpc.php, а сам протокол не используется, блокировка имеет смысл.

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

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

Посмотрите access log веб-сервера. Для Apache и Nginx путь к логам отличается, но сама проверка одинаковая: ищете обращения к /xmlrpc.php и смотрите частоту.

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

Если у вас Apache, путь может быть другим:

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

Полезно проверить и ответ сервера снаружи:

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

Если видите 200, 405 или просто страницу с ответом WordPress, значит файл доступен. Для жёсткой блокировки на уровне сервера нужен 403.

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

Самый надёжный вариант — блокировать доступ на уровне веб-сервера. Но если вы не можете менять конфиг сервера, можно добавить фильтр в WordPress. Это не так эффективно, потому что PHP всё равно запускается, но для многих проектов этого достаточно.

Вариант 1: блокировка через functions.php или mu-plugin

Этот способ подходит, если у вас нет доступа к настройкам Nginx/Apache или вы хотите быстро проверить эффект. Добавьте код в functions.php дочерней темы или, лучше, в mu-plugin.

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

add_filter('wp_headers', function ($headers) {
    if (isset($_SERVER['REQUEST_URI']) && strpos($_SERVER['REQUEST_URI'], 'xmlrpc.php') !== false) {
        $headers['X-Robots-Tag'] = 'noindex, nofollow';
    }
    return $headers;
});

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

Вариант 2: жёсткая блокировка на Nginx

Если сайт работает на Nginx, добавьте отдельное правило в конфиг сайта. Это лучший вариант по производительности: запросы отсекаются до запуска PHP-FPM.

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

После изменения проверьте конфигурацию и перезагрузите Nginx:

nginx -t
systemctl reload nginx

При корректной настройке curl -I https://example.com/xmlrpc.php должен вернуть 403 Forbidden.

Вариант 3: блокировка в Apache

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

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

После этого Apache должен отдавать 403 на прямой запрос к файлу. Если правило не сработало, проверьте, разрешён ли AllowOverride для нужной директории.

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

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

Подход	Что даёт	Минус
Nginx/Apache	403 до PHP, меньше нагрузки	Нужен доступ к конфигу
Код в WordPress	Быстро внедрить без сервера	PHP всё равно стартует
Плагин безопасности	Удобно для админов без доступа к серверу	Лишняя зависимость и возможные конфликты

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

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

Проверка должна быть не только «в браузере ничего не открывается». Нужны три шага: ответ сервера, отсутствие доступа из WordPress и отсутствие лишних обращений в логах.

Выполните curl -I https://example.com/xmlrpc.php и убедитесь, что получаете 403.
Проверьте, не используют ли внешние сервисы публикации или мобильные клиенты XML-RPC.
Посмотрите access log через 1–2 дня и убедитесь, что запросы больше не доходят до PHP.

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

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

Сайт отдаёт 403 не только на xmlrpc.php

Обычно это ошибка в правиле Nginx или Apache. Проверьте, что блокируется именно файл /xmlrpc.php, а не весь каталог или весь сайт. В Nginx используйте точное совпадение location = /xmlrpc.php.

После отключения перестала работать публикация из внешнего сервиса

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

Код в functions.php не сработал

Частая причина — код добавили в активную тему, а потом переключили тему или обновили её. Для системных ограничений лучше использовать mu-plugin, чтобы правило не зависело от темы.

Плагин безопасности конфликтует с кэшем или WAF

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

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

Если вы закрываете XML-RPC ради защиты, не останавливайтесь на одном файле. Проверьте ещё и другие точки, которые часто атакуют автоматически: /wp-login.php, устаревшие плагины, открытые REST-эндпоинты с лишними данными. Но не блокируйте всё подряд без анализа — можно сломать нормальные сценарии входа и интеграции.

Для сайтов на VPS полезно держать отдельный мониторинг по access log: когда всплеск запросов к xmlrpc.php повторяется, это уже не абстрактная «угроза из интернета», а конкретная нагрузка на ваш сервер. В такой ситуации серверная блокировка даёт заметный практический эффект, потому что отсекает шум до PHP и не тратит ресурсы на обработку заведомо лишних запросов.

Если нужен более широкий аудит технических дублей, служебных страниц и лишних точек входа, имеет смысл смотреть не только на XML-RPC, но и на общую чистку сайта. Для этого в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy.