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

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

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

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

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

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

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

тогда сначала проверьте, можно ли перевести их на REST API или другой способ авторизации. Иначе после отключения получите не «усиление безопасности», а сломанный рабочий процесс.

Диагностика: кто стучится в xmlrpc.php

Перед изменениями полезно посмотреть, есть ли вообще обращения к этому файлу. На уровне веб-сервера это видно в логах. Например, в Nginx можно быстро отфильтровать запросы:

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

Если у вас Apache, ищите аналогично в access log. Важны не только частота запросов, но и источник: один и тот же IP, разные IP, всплески POST-запросов, попытки авторизации. Если в логах идут регулярные обращения без понятной причины, это хороший кандидат на отключение.

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

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

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

Способ	Плюсы	Минусы
Плагин безопасности	Быстро, без правки кода	Дополнительная зависимость, не всегда точечная настройка
Код в теме или mu-plugin	Контроль, минимум лишнего	Нужно аккуратно обновлять и не потерять при смене темы
Правило на сервере	Запросы режутся до WordPress	Нужен доступ к конфигу Nginx/Apache

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

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

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

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

Вариант 2: блокировка на уровне веб-сервера

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

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

Для Apache обычно используют правило в .htaccess или конфигурации виртуального хоста:

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

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

Вариант 3: плагин безопасности

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

Пошаговое решение для боевого сайта

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

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

Проверка должна быть не «страница вроде открывается», а конкретная.

Откройте /xmlrpc.php в браузере — при серверной блокировке должен быть отказ в доступе, а не обычный ответ WordPress.
Сделайте запрос через curl и посмотрите код ответа:

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

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

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

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

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

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

Добавили код в родительскую тему и потеряли его после обновления

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

Закрыли файл на сервере, но забыли про интеграцию

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

Поставили тяжёлый security-плагин только ради одной функции

Это не всегда оправдано. Если задача одна — отключить XML-RPC, проще и надёжнее использовать фильтр или правило веб-сервера. Лишний плагин — это ещё один кодовый слой, который нужно обновлять и проверять.

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

Если вы отключаете XML-RPC ради защиты, не останавливайтесь на одном файле. Проверьте ещё несколько точек входа:

убедитесь, что включён актуальный механизм защиты входа в админку;
ограничьте число попыток авторизации, если это уместно;
проверьте, не оставлены ли старые интеграции с внешними сервисами;
посмотрите, нет ли лишних запросов к wp-login.php и admin-ajax.php.

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

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

Когда лучше не отключать

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

ограничить доступ по IP, если это возможно;
усилить защиту авторизации;
следить за логами и аномалиями;
планировать миграцию на REST API или другой современный способ интеграции.

Такой подход практичнее, чем резкое отключение без анализа последствий. WordPress в этом месте не требует героизма — только аккуратной проверки зависимостей.