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

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

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

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

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

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

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

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

Если логов нет, можно временно проверить ответ напрямую. При активном XML-RPC WordPress обычно отвечает на запросы к /xmlrpc.php, а при блокировке — отдает 403 или 404 в зависимости от способа отключения.

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

Этот запрос не доказывает, что XML-RPC используется, но показывает, доступен ли сам endpoint. Если ответ 200 или 405, файл доступен. Если 403 или 404, доступ уже закрыт на уровне сервера или WordPress.

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

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

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

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

Способ 1. Отключить XML-RPC через код

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

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

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

Способ 2. Закрыть xmlrpc.php на сервере

Если задача — не просто выключить функциональность, а убрать лишние запросы еще до запуска WordPress, можно закрыть файл на уровне веб-сервера. Для Apache подойдет правило в .htaccess, для nginx — отдельный location или deny-правило.

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

Для nginx конфигурация зависит от схемы сайта, но смысл тот же: запросы к /xmlrpc.php должны завершаться до передачи в PHP. Это уменьшает шум от ботов и не дает им нагружать WordPress лишними обращениями.

Способ 3. Использовать плагин безопасности

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

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

Пошаговое решение без риска для рабочих интеграций

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

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

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

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

Проверка должна быть не только технической, но и функциональной. Недостаточно увидеть 403 в браузере — нужно убедиться, что сайт не потерял нужные сценарии.

Минимальный чек-лист проверки

• открывается ли https://example.com/xmlrpc.php и какой код ответа возвращается;
• не появились ли ошибки в error log PHP и веб-сервера;
• работает ли вход в админку и обычная публикация записей;
• не отвалился ли Jetpack или другой подключенный сервис;
• не растет ли число 404/403 на xmlrpc.php после изменения;
• если используется CDN или WAF, не дублируется ли блокировка на нескольких уровнях.

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

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

Второй запрос полезен как контрольный: если вы отключали XML-RPC ради безопасности, REST API при этом должен оставаться доступным, если вы сами его не ограничивали.

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

Отключили XML-RPC и сломали Jetpack

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

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

Если WordPress отвечает 403, но запросы продолжают идти, значит боты все еще тратят ресурсы на вход в стек. В этом случае лучше добавить блокировку на уровне веб-сервера или WAF, чтобы не запускать PHP вообще.

Поставили несколько плагинов защиты с одинаковой функцией

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

Проверили только главную страницу

Это типичная ошибка. Главная может работать, а интеграция уже отвалилась. Проверяйте именно endpoint /xmlrpc.php, логи и реальные сценарии публикации или синхронизации.

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

Иногда отключать его полностью нельзя. Тогда задача меняется: не убрать функцию, а ограничить поверхность атаки. В таком случае имеет смысл закрыть доступ по IP, поставить WAF-правила, ограничить частоту запросов и пересмотреть, можно ли заменить XML-RPC на REST API или прямую интеграцию через плагин.

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

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