Как отключить XML-RPC в WordPress и не сломать нужные подключения

Автор: Елена Алексеева | Опубликовано: 27.09.2026

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

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

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

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

Типичные признаки, что XML-RPC не нужен

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

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

Диагностика: как понять, используется ли xmlrpc.php

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

Если есть SSH-доступ, можно быстро проверить обращения по логам так:

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

Для Apache путь к логам может отличаться, но логика та же: ищем запросы к xmlrpc.php и смотрим, это реальные клиенты или массовые сканеры. Если видите только однотипные POST-запросы с разных IP, это не аргумент в пользу сохранения XML-RPC.

Ещё один полезный тест — открыть URL /xmlrpc.php в браузере. Нормальный ответ WordPress обычно сообщает, что XML-RPC сервер принимает только POST-запросы. Это не означает, что интерфейс безопасен или нужен, но подтверждает, что файл доступен.

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

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

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

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

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

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

Такой код лучше размещать в небольшом mu-plugin, а не в теме. Тогда он не пропадёт после смены шаблона. Пример минимального файла:

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Файл положите в wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную.

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

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

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

После изменения конфигурации проверьте синтаксис и перезагрузите nginx. Не правьте основной конфиг вслепую: на некоторых хостингах правила нужно добавлять в отдельный include-файл или через панель управления.

Вариант 3: ограничить доступ через Apache

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

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

Этот вариант удобен, если у вас нет желания ставить дополнительный плагин и вы контролируете конфигурацию сайта. Но если хостинг переписывает .htaccess, убедитесь, что правило не будет удалено при очередном обновлении панели.

Пошаговое решение без лишнего риска

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

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

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

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

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

Что проверить после внедрения

открыть /xmlrpc.php и убедиться, что доступ запрещён или ответ не позволяет использовать интерфейс;
проверить лог веб-сервера: новых успешных обращений к xmlrpc.php быть не должно;
если есть Jetpack или внешняя публикация, протестировать их отдельно;
проверить, что REST API и обычная авторизация в админке работают как раньше;
посмотреть, не появились ли ошибки 403/500 в логах после изменения.

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

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

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

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

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

Ошибка 1: правят functions.php вместо mu-plugin

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

Ошибка 2: блокируют только в плагине безопасности, но оставляют доступ на сервере

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

Ошибка 3: не проверяют мобильные и старые интеграции

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

Ошибка 4: путают отключение XML-RPC с отключением REST API

Это разные механизмы. Отключение XML-RPC не влияет на REST API напрямую. Если после изменения у вас перестали работать другие интеграции, ищите причину в другом месте: в правилах безопасности, кэше, авторизации или CORS.

Что делать, если XML-RPC нужен частично

Иногда интерфейс нужен только для одного сервиса, а всё остальное вы хотите закрыть. В таких случаях лучше не держать XML-RPC открытым полностью, а ограничить доступ на уровне сети или сервера. Например, можно разрешить запросы только с конкретных IP-адресов или через отдельный reverse proxy. Это уже более сложная схема, но она лучше, чем «включено для всех».

Если ограничение по IP невозможно, иногда проще перейти на REST API или другой механизм интеграции. Это не всегда делается за один день, но в долгую такой путь обычно чище, чем поддержка устаревшего интерфейса ради одного сценария.

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

Отключение XML-RPC само по себе не делает сайт «защищённым», но убирает лишнюю поверхность атаки. На сайтах с постоянными брутфорс-запросами это ещё и снижает шум в логах. Если у вас уже настроены лимиты на уровне WAF, CDN или fail2ban, отключение XML-RPC хорошо дополняет общую схему, но не заменяет её.

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

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