Как отключить XML-RPC в WordPress и защитить сайт от брутфорса

Автор: Алина Полякова | Опубликовано: 24.08.2026

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

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

Когда XML-RPC действительно мешает

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

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

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

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

Диагностика: как понять, что XML-RPC используется

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

Быстрая проверка через браузер и curl

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

Если файл доступен, это ещё не значит, что он используется, но значит, что точка входа открыта. Для проверки блокировки после настройки удобнее смотреть именно HTTP-ответ.

В логах часто видно повторяющиеся обращения с одинаковым шаблоном. Если у вас Nginx или Apache, ищите запросы к /xmlrpc.php с кодами 200, 403 или 401. Большое число попыток авторизации — типичный признак брутфорса.

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

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

Способ	Когда подходит	Минус
Код в functions.php или mu-plugin	Нужен точный контроль внутри WordPress	Не защищает точку входа на уровне веб-сервера
.htaccess / Nginx	Нужно отрезать запросы до загрузки WordPress	Требует доступа к конфигу сервера
Плагин безопасности	Нужна быстрая настройка без кода	Добавляет зависимость от плагина

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

Если вы хотите оставить сайт управляемым из WordPress, но убрать сам механизм XML-RPC, используйте фильтр xmlrpc_enabled. Это стандартный и проверяемый способ.

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

Код можно добавить в functions.php дочерней темы или, что надёжнее, в небольшой mu-plugin. Второй вариант удобнее, потому что он не зависит от смены темы.

Вариант 2: заблокировать xmlrpc.php на уровне сервера

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

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

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

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

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

Вариант 3: отключить только опасные методы

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

Пошаговое решение без сюрпризов

Проверьте, не использует ли сайт мобильное приложение WordPress, Jetpack или внешнюю публикацию.
Сделайте резервную копию файла конфигурации или подготовьте отдельный mu-plugin.
Добавьте add_filter( 'xmlrpc_enabled', '__return_false' ); или серверное правило блокировки.
Очистите кеш, если у вас включён page cache или CDN.
Проверьте ответ /xmlrpc.php и логи запросов.

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

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

Проверка должна быть не «страница открывается/не открывается», а именно по поведению точки входа и по логам.

Что должно измениться

Запрос к /xmlrpc.php возвращает 403 Forbidden или другой запретительный код, если блокировка на сервере.
Если отключение сделано через фильтр WordPress, XML-RPC перестаёт отвечать как рабочий интерфейс, но файл может быть доступен на уровне веб-сервера.
В логах снижается число обращений к xmlrpc.php от ботов.

Проверить ответ можно так:

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

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

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

После отключения перестало работать приложение WordPress

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

Jetpack начал ругаться на соединение

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

Сайт всё ещё получает много запросов

Если блокировка сделана только в WordPress, сервер всё равно принимает запросы и тратит ресурсы на их обработку. В этом случае лучше перенести запрет на уровень Nginx или Apache.

После правки .htaccess сайт начал отдавать 500

Обычно причина в синтаксисе или в том, что правило вставили не в тот блок. Верните резервную копию файла и проверьте, поддерживает ли ваш сервер директиву Require all denied. На старых конфигурациях Apache могут быть нюансы с версией и модулем доступа.

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

Отключение XML-RPC само по себе не заменяет защиту входа в админку. Если сайт атакуют брутфорсом, параллельно проверьте:

сложность паролей у администраторов;
наличие двухфакторной аутентификации, если она у вас уже внедрена;
ограничение попыток входа;
наличие актуальных обновлений WordPress, тем и плагинов.

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

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

Короткий чек-лист перед публикацией изменений

Проверил, не нужен ли XML-RPC для мобильного приложения или Jetpack.
Сохранил резервную копию .htaccess или конфигурации Nginx.
Добавил отключение через фильтр или серверное правило.
Очистил кеш сайта и CDN.
Проверил /xmlrpc.php через curl.
Посмотрел логи на предмет повторных обращений и ошибок.

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