Как отключить XML-RPC в WordPress без поломки Jetpack и мобильных приложений

Автор: Вадим Васильев | Опубликовано: 23.08.2026

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

Если задача — убрать лишнюю поверхность атаки, снизить шум от брутфорса и не сломать рабочие сценарии, лучше идти по шагам: сначала диагностика, потом отключение, затем проверка ответов сервера и логов.

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

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

Что обычно ломается после отключения

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

Диагностика: проверяем, нужен ли xmlrpc.php

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

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

Обычно вы увидите ответ 405 Method Not Allowed или 200 OK с текстом о том, что XML-RPC сервер принимает только POST-запросы. Это нормально. Важнее понять, есть ли реальные обращения в логах.

Если есть доступ к access log веб-сервера, ищите запросы к /xmlrpc.php. На типичном сайте это либо редкие обращения от легитимных сервисов, либо постоянный шум от ботов.

grep "xmlrpc.php" /var/log/nginx/access.log

Если логов нет, проверьте список активных интеграций вручную:

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

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

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

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

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

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

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

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

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

Если цель — не просто отключить функцию, а уменьшить нагрузку от ботов, лучше резать запросы раньше PHP. Для Nginx можно вернуть 403 на прямые обращения к файлу:

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

В Apache аналогичный эффект можно получить через правила в .htaccess:

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

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

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

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

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

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

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

выполните curl -I https://example.com/xmlrpc.php и убедитесь, что сервер возвращает 403 или другой ожидаемый код отказа;
если отключали через фильтр, попробуйте отправить тестовый XML-RPC запрос из внешнего клиента и проверьте, что авторизация не проходит;
откройте логи веб-сервера и убедитесь, что обращения к /xmlrpc.php больше не доходят до PHP;
проверьте Jetpack, мобильное приложение WordPress и другие интеграции, если они используются;
посмотрите, не появились ли ошибки в debug.log или в логах плагинов синхронизации.

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

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

Отключили XML-RPC, не проверив Jetpack

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

Заблокировали файл в .htaccess, но забыли про Nginx

Если сайт работает на Nginx, правило из .htaccess не поможет. Нужно править конфиг Nginx или отключать через WordPress-фильтр. И наоборот: на Apache правило в конфиге Nginx не имеет смысла.

Поставили плагин безопасности и не поняли, что именно он меняет

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

Сломали внешнюю публикацию, но не нашли источник

Если в проекте несколько редакторов и подрядчиков, часто никто не помнит, какой сервис подключали полгода назад. В этом случае ищите не только в админке WordPress, но и в списке доступов к сторонним системам: планировщикам публикаций, CRM, мониторингу и мобильным клиентам.

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

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

используйте отдельный mu-plugin для точечных ограничений, если не хотите зависеть от темы;
не смешивайте отключение XML-RPC с другими изменениями безопасности в одном большом файле без комментариев;
после правок проверьте, не выросла ли нагрузка на wp-login.php — иногда боты просто переключаются на другой путь;
если нужен удалённый доступ к контенту, рассмотрите REST API вместо старого XML-RPC.

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

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