Как отключить XML-RPC в WordPress и защитить сайт от brute-force атак

Автор: Людмила Соколова | Опубликовано: 26.08.2026

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

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

Когда XML-RPC можно отключать, а когда нет

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

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

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

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

Проверить, открыт ли endpoint, можно обычным запросом к /xmlrpc.php. Если он отвечает, это ещё не значит, что им кто-то пользуется, но значит, точка доступа доступна извне.

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

Типичный ответ при доступности endpoint — HTTP 200 или 405 с текстом о том, что XML-RPC server accepts POST requests only. Это нормальное поведение для включённого XML-RPC.

Дополнительно посмотрите логи веб-сервера. Если там много запросов к xmlrpc.php с разных IP и неудачные попытки авторизации, это уже практический сигнал, что endpoint используют для перебора.

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

Есть три рабочих подхода: через плагин, через код и на уровне веб-сервера. Выбор зависит от того, как у вас устроен проект.

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

Вариант 1: отключение через код

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

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter('xmlrpc_enabled', '__return_false');

Этот фильтр отключает XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно.

Если хотите не просто отключить функциональность, а ещё и возвращать 403 на сам запрос к xmlrpc.php, можно добавить отдельную проверку:

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

Но здесь есть нюанс: XMLRPC_REQUEST срабатывает уже внутри WordPress. То есть запрос до PHP всё равно дойдёт. Если цель — снизить нагрузку и отрезать трафик раньше, лучше блокировать на уровне веб-сервера.

Вариант 2: блокировка в nginx

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

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

Такой блок не даёт запросу даже дойти до WordPress. Для сайтов с заметным фоном атак это обычно лучший вариант.

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

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

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

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

Что проверить после отключения

Отключение считается успешным не тогда, когда «ничего не сломалось», а когда endpoint реально перестал принимать запросы и не затронул нужные интеграции.

Откройте /xmlrpc.php в браузере или через curl.
Проверьте, что ответ стал 403 Forbidden или 404 Not Found, если вы закрывали доступ на сервере.
Убедитесь, что вход в админку работает как раньше.
Если используете Jetpack или внешние публикации, протестируйте именно эти сценарии.
Посмотрите логи веб-сервера: запросы к xmlrpc.php должны либо исчезнуть, либо получать отказ.

Для быстрой проверки через командную строку удобно смотреть код ответа:

curl -o /dev/null -s -w "%{http_code}\n" https://example.com/xmlrpc.php

Если вы отключали XML-RPC через фильтр WordPress, код ответа может отличаться от серверной блокировки. Главное — endpoint не должен принимать рабочие XML-RPC-запросы.

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

Отключили XML-RPC, а Jetpack перестал синхронизироваться

Это типичный сценарий. Сначала проверьте, действительно ли Jetpack использует XML-RPC в вашей конфигурации. Если да, не отключайте endpoint без замены. Вариантов немного: либо оставить XML-RPC включённым и закрыть его другими мерами, либо пересмотреть набор функций Jetpack.

Закрыли доступ в .htaccess, но endpoint всё равно отвечает

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

Добавили код в тему и потеряли защиту после обновления

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

Поставили плагин, который отключает XML-RPC, но оставили лишние функции

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

Чек-лист перед выкладкой на боевой сайт

Проверили, не используется ли XML-RPC внешними сервисами.
Сделали резервную копию конфигурации сервера или файла с правками.
Выбрали один способ отключения, а не несколько одновременно без необходимости.
Протестировали /xmlrpc.php после изменений.
Проверили вход в админку, публикацию записей и подключённые интеграции.
Посмотрели логи на предмет ошибок 403/500 и неожиданных отказов.

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

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

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

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

Главная идея простая: если XML-RPC вам не нужен, не оставляйте его открытым «на всякий случай». Если нужен — не рубите с плеча, сначала проверьте зависимости и только потом выбирайте способ блокировки.