Как отключить XML-RPC в WordPress и не сломать Jetpack, мобильные приложения и внешние сервисы

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

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

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

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

• в логах видны регулярные запросы к /xmlrpc.php;
• на сайте идут попытки брутфорса через system.multicall;
• нужна минимизация лишних публичных точек входа;
• интеграции уже переведены на REST API или вообще не используются.

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

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

Самый простой способ — посмотреть, есть ли обращения к файлу в access log веб-сервера. Если логов нет под рукой, можно временно открыть https://example.com/xmlrpc.php в браузере: при доступности файла WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не доказывает, что он нужен, но подтверждает, что endpoint открыт.

Полезнее проверить и сам сайт, и окружение:

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

Что искать в логах

В access log часто видно либо массовые запросы с одного IP, либо короткие серии POST с одинаковым user-agent. Это уже повод не просто отключать XML-RPC, а смотреть на общую защиту входа: лимиты, WAF, fail2ban, reCAPTCHA на форме входа и актуальность паролей.

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

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

Как отключить XML-RPC: три рабочих подхода

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

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

Это удобный способ, если вы хотите управлять поведением из репозитория или mu-plugins. Добавьте код в functions.php дочерней темы или, лучше, в отдельный must-use плагин.

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

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

Вариант 2: закрыть xmlrpc.php на уровне Nginx

Если вы используете Nginx, можно отдать 444 или 403 для /xmlrpc.php. Это полезно, когда нужно остановить поток запросов до загрузки WordPress.

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

Если у вас уже есть отдельные правила безопасности, проверьте, не конфликтует ли это с ними. Иногда deny all дублируется в другом include-файле, и потом сложно понять, какое правило реально сработало.

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

Для Apache можно закрыть endpoint через .htaccess или конфиг виртуального хоста. Это особенно удобно на shared-хостинге, где нет доступа к основному конфигу.

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

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

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

После отключения важно не ограничиваться тем, что страница перестала открываться в браузере. Нужна проверка именно по сценариям использования.

• Откройте /xmlrpc.php в браузере — доступ должен быть закрыт или ответ должен быть неуспешным.
• Проверьте лог сервера: новых обращений к endpoint быть не должно, либо они должны получать отказ.
• Если используется Jetpack, проверьте его статус в админке WordPress.
• Если есть внешняя публикация или мобильный клиент, протестируйте авторизацию и отправку записи.

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

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

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

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

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

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

Заблокировали только WordPress-фильтром, но endpoint все равно отвечает

Фильтр xmlrpc_enabled отключает обработку внутри WordPress, но сам файл xmlrpc.php остается доступным на уровне веб-сервера. Для большинства задач этого хватает, но если цель — снизить шум от атак и сэкономить ресурсы, лучше добавить блокировку на сервере.

Сломали мобильное приложение или старый клиент публикации

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

Сделали блокировку в .htaccess, но она не сработала

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

Что еще стоит сделать вместе с отключением XML-RPC

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

• включите ограничение попыток входа, если его нет;
• проверьте, не открыт ли /wp-login.php без защиты;
• убедитесь, что актуальны ядро, темы и плагины;
• посмотрите, не остались ли лишние REST-эндпоинты от старых плагинов;
• если сайт большой, добавьте мониторинг 4xx/5xx и всплесков запросов к входным точкам.

Для сайтов, где нужно быстро убрать лишние технические дубли, скрыть мусорные элементы и почистить SEO-настройки, иногда удобнее использовать специализированный набор инструментов вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpturbo.ru&utm_medium=article&utm_campaign=otklyuchit-xml-rpc-v-wordpress. Но даже в этом случае полезно понимать, что именно отключается и где это происходит — в WordPress или на сервере.

Как выбрать подход: код, сервер или плагин

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

Практически это выглядит так: сначала вы проверяете, нужен ли XML-RPC вообще; затем отключаете его самым подходящим способом; после этого тестируете реальные интеграции и смотрите логи еще несколько дней. Такой порядок экономит время лучше, чем «поставить галочку и надеяться».