XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация через старые клиенты или отдельные интеграции. Проблема в том, что у этого механизма есть реальные потребители, и отключать его нужно не по привычке, а после проверки, используется ли он вообще.
Если задача именно убрать лишний входной вектор и сократить поверхность атаки, лучше сначала понять, кто обращается к /xmlrpc.php, а уже потом выбрать способ блокировки: на уровне плагина, темы, сервера или через WAF. Ниже — рабочий сценарий без выдуманных хуков и без «магии».
Когда XML-RPC действительно стоит отключать
Отключение оправдано, если сайт не использует старые внешние клиенты, Jetpack с функциями, завязанными на XML-RPC, и удалённую публикацию через приложения, которым нужен именно этот протокол. На практике чаще всего это обычный сайт с входом в админку, REST API и без сторонних сервисов, которые стучатся в XML-RPC.
Если у вас только WordPress-админка, современная тема и стандартные плагины, XML-RPC обычно не нужен. Но если сайт подключён к Jetpack, мобильному приложению WordPress или старому сервису автопостинга, отключение может сломать часть сценариев. Поэтому сначала диагностика, потом действие.
Диагностика: используется ли xmlrpc.php на вашем сайте
Самый быстрый способ — посмотреть логи веб-сервера или логи WAF/Cloudflare, если они у вас есть. Ищите обращения к /xmlrpc.php. Если запросы идут регулярно, это уже сигнал, что кто-то или что-то использует endpoint.
Если доступа к логам нет, проверьте функциональные зависимости вручную:
- используется ли Jetpack и включены ли функции, которым нужен XML-RPC;
- есть ли мобильное приложение WordPress, подключённое к сайту;
- есть ли внешняя публикация из сторонних сервисов;
- не настроены ли старые клиенты для публикации по XML-RPC;
- не завязаны ли на него интеграции из CRM или автопостинга.
Если сомневаетесь, временно ограничьте доступ к /xmlrpc.php на уровне сервера и проверьте, что ломается. Это безопаснее, чем сразу удалять поддержку из кода темы или плагинов.
Как отключить XML-RPC: сравнение подходов
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | Нужна быстрая настройка без кода | Просто включить, часто есть дополнительные проверки | Лишний плагин, зависит от его качества |
| Код в теме или mu-plugin | Нужен контролируемый вариант без лишних зависимостей | Прозрачно, легко ревизировать | Нужно понимать, где хранить код |
| Блокировка на сервере | Есть доступ к nginx/apache или WAF | Режет запросы раньше WordPress | Можно задеть легитимные сценарии, если не проверить зависимости |
Пошаговое решение через код
Если вам нужен предсказуемый вариант без отдельного плагина, добавьте фильтр xmlrpc_enabled. Это штатный способ отключить XML-RPC в WordPress.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
Код можно положить в functions.php дочерней темы, но для технической чистоты лучше использовать небольшой mu-plugin, чтобы он не зависел от смены темы. Например, создайте файл wp-content/mu-plugins/disable-xmlrpc.php:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
Такой вариант не требует активации в админке и работает стабильно после обновлений темы.
Если нужно не отключить, а только закрыть доступ извне
Иногда удобнее оставить XML-RPC включённым для внутренних сценариев, но запретить прямые обращения снаружи на уровне веб-сервера или WAF. Это уже зависит от инфраструктуры. Для nginx часто используют отдельное правило в конфигурации, а для Cloudflare — правило блокировки по URI /xmlrpc.php.
Но здесь важно не переусердствовать: если у вас есть легитимный клиент, который обращается к этому файлу, он тоже перестанет работать. Поэтому сначала проверьте логи, потом режьте.
Проверка результата после внедрения
После добавления фильтра откройте /xmlrpc.php в браузере или выполните запрос через curl. Поведение должно измениться: WordPress не должен принимать XML-RPC вызовы как раньше.
curl -i https://example.com/xmlrpc.phpДальше проверьте прикладные сценарии:
- если используется Jetpack — убедитесь, что нужные функции продолжают работать;
- если есть мобильное приложение WordPress — попробуйте авторизацию и публикацию;
- если есть внешняя интеграция — проверьте отправку тестового поста;
- посмотрите логи сервера: запросы к
/xmlrpc.phpдолжны либо исчезнуть, либо получать ожидаемый отказ.
Если после отключения что-то сломалось, значит XML-RPC реально был нужен. В этом случае не пытайтесь «починить» его через случайные сниппеты из интернета — лучше вернуть поддержку и уже отдельно ограничить доступ по IP, токену или через WAF.
Частые ошибки и как их исправить
Отключили XML-RPC и потеряли Jetpack
Это типичная ситуация, когда сначала отключают, а потом выясняется, что Jetpack использовал XML-RPC для части функций. Решение простое: либо вернуть поддержку, либо перенести нужные сценарии на альтернативный способ подключения, если он доступен в вашей конфигурации.
Добавили код в родительскую тему
После обновления темы фильтр исчезает, и XML-RPC снова включается. Если решение должно жить долго, используйте дочернюю тему или mu-plugin.
Блокируют только в WordPress, но не на сервере
Это не ошибка, но и не полная защита. Запрос всё равно доходит до PHP и создаёт нагрузку. Если цель — именно безопасность и снижение мусорного трафика, лучше закрывать endpoint раньше, на уровне nginx/apache или WAF.
Путают XML-RPC и REST API
Отключение XML-RPC не выключает REST API. Если после изменений у вас перестали работать интеграции, проверьте, что проблема действительно в XML-RPC, а не в другом механизме авторизации или в кэше.
Практические советы по безопасности и производительности
Если сайт регулярно получает брутфорс по /xmlrpc.php, отключение этого endpoint часто уменьшает шум в логах и нагрузку на PHP. Но не стоит считать это полноценной защитой от атак: парольная защита админки, ограничение попыток входа, обновления ядра и плагинов остаются обязательными.
Для сайтов с высокой посещаемостью лучше сочетать несколько уровней:
- отключить XML-RPC, если он не нужен;
- закрыть endpoint на уровне сервера или WAF;
- не хранить лишние функции в
functions.php, если можно использовать mu-plugin; - проверить, нет ли в логах повторяющихся обращений от ботов и сканеров.
Если вам нужен более широкий набор мер по чистке сайта и отключению лишних механизмов, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае полезно понимать, что именно вы отключаете и почему.
Что проверить после публикации изменений
- XML-RPC endpoint больше не принимает запросы без необходимости.
- Jetpack и мобильное приложение WordPress не потеряли нужные функции.
- В логах нет новых ошибок, связанных с
xmlrpc.php. - Изменение сохранено в дочерней теме или mu-plugin, а не в файле, который легко перезаписать обновлением.
- Если доступ закрыт на сервере, правила не конфликтуют с другими rewrite-настройками.
Если нужен именно безопасный и проверяемый результат, ориентируйтесь не на сам факт отключения, а на то, что после него не сломались реальные сценарии сайта. В WordPress это важнее любой «универсальной» рекомендации.