XML-RPC в WordPress часто оставляют включенным по привычке, а потом удивляются лишним запросам, попыткам брутфорса и странным обращениям к /xmlrpc.php. Но отключать его вслепую тоже плохая идея: на некоторых сайтах через него до сих пор работают внешние публикации, старые мобильные клиенты и интеграции с сервисами автоматизации.
Ниже — практический сценарий: как понять, нужен ли XML-RPC именно вашему сайту, как отключить его безопасно и как проверить, что ничего не отвалилось.
Когда XML-RPC действительно можно отключать
Если вы не пользуетесь внешней публикацией через старые клиенты WordPress, не подключали сервисы, которые ходят в сайт через XML-RPC, и не видите в логах легитимных обращений к этому endpoint, его обычно можно закрыть. Для большинства современных сайтов достаточно REST API и обычной админки.
Но перед изменениями проверьте зависимости. Особенно это важно, если сайт старый, на нем есть интеграции с CRM, автопостингом, планировщиками публикаций или мобильными приложениями, которые были настроены давно и документированы плохо.
Что проверить в первую очередь
- есть ли обращения к
/xmlrpc.phpв access-логах веб-сервера; - используются ли внешние сервисы для публикации или обновления записей;
- не завязаны ли на XML-RPC сторонние плагины синхронизации;
- не работает ли старая мобильная админка или клиент WordPress;
- не настроены ли мониторинги, которые ошибочно считают XML-RPC частью нормального трафика.
Диагностика: как понять, кто обращается к xmlrpc.php
Самый полезный шаг — посмотреть логи. Если у вас есть доступ к access.log, найдите обращения к xmlrpc.php. Это покажет, идут ли запросы от реальных сервисов или это массовые попытки подбора паролей.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если хостинг не дает доступ к логам, можно временно включить запись на уровне веб-сервера или посмотреть статистику в панели. Важно не гадать, а сначала увидеть источник запросов.
Еще один практичный признак: если после отключения XML-RPC у вас перестают работать внешние публикации или синхронизация, значит зависимость была реальной. В таком случае лучше не блокировать endpoint полностью, а ограничить доступ по IP или закрыть только лишние методы.
Пошаговое решение: как отключить XML-RPC безопасно
Есть три рабочих подхода: через плагин, через код и на уровне веб-сервера. Выбор зависит от того, нужен ли вам быстрый откат и насколько жестко вы хотите закрыть endpoint.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин | Нужно быстро включать/выключать защиту | Просто откатить, меньше риска ошибиться | Дополнительная зависимость |
| Код в теме или mu-plugin | Нужен контроль без лишних плагинов | Прозрачно, легко версионировать | Нужно аккуратно тестировать |
| .htaccess / nginx | Нужно блокировать запросы до WordPress | Меньше нагрузки, запросы не доходят до PHP | Нужен доступ к конфигу сервера |
Вариант 1: отключить XML-RPC через код
Самый понятный способ — добавить фильтр xmlrpc_enabled. Это не ломает сайт, а просто говорит WordPress не принимать XML-RPC запросы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если вы не хотите править functions.php активной темы, лучше положить этот код в mu-plugin. Тогда он не исчезнет после смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Вариант 2: заблокировать запросы на уровне nginx
Если вы используете nginx, можно отрезать запросы к /xmlrpc.php до передачи в PHP. Это полезно, когда сайт регулярно получает мусорный трафик и вы хотите снизить нагрузку.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой вариант особенно хорош для сайтов с высокой атакующей активностью. Но если у вас есть легитимные интеграции, сначала убедитесь, что они не используют XML-RPC.
Вариант 3: блокировка через .htaccess
На Apache можно закрыть файл через .htaccess. Это рабочий вариант для обычного shared-хостинга.
<Files xmlrpc.php>
Require all denied
</Files>Если сервер старый и использует Apache 2.2, синтаксис может отличаться, но на современных установках лучше использовать именно Require all denied.
Как не сломать мобильные приложения и внешние сервисы
Главная ошибка — отключить XML-RPC на живом сайте без проверки интеграций. Если у вас есть внешние сервисы, которые публикуют записи, обновляют статусы или отправляют контент, они могут перестать работать без явной ошибки в админке.
Безопаснее идти по схеме: сначала посмотреть логи, потом отключить XML-RPC на тестовой копии, затем проверить реальные сценарии. Если интеграция нужна только одному сервису, иногда разумнее ограничить доступ по IP, а не закрывать endpoint полностью.
Чек-лист перед отключением
- сделайте резервную копию конфигурации сервера и сайта;
- проверьте, нет ли активных интеграций через XML-RPC;
- посмотрите логи за последние дни, а не только за один час;
- протестируйте публикацию и редактирование записей после изменения;
- убедитесь, что REST API и админка работают штатно.
Проверка результата после внедрения
После отключения откройте /xmlrpc.php в браузере или через curl. Если блокировка настроена правильно, вы не должны получать нормальный XML-RPC ответ WordPress.
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали через WordPress-фильтр, запрос может вернуть стандартный ответ об отключенном XML-RPC или ошибку доступа, в зависимости от способа проверки. Если блокировали на уровне nginx или Apache, запрос должен отрезаться раньше, чем дойдет до PHP.
Дальше проверьте рабочие сценарии:
- вход в админку;
- создание и обновление записи;
- работу REST API, если он используется вашим редактором или плагинами;
- публикацию через внешние сервисы, если они у вас есть;
- отсутствие новых ошибок в логах после блокировки.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про интеграцию
Симптом: внешняя публикация перестала работать, а в интерфейсе сервиса нет понятной ошибки. Решение: временно вернуть доступ, найти источник запросов в логах и либо оставить XML-RPC включенным, либо ограничить его по IP.
Добавили код в активную тему и потеряли его после обновления
Если фильтр лежит в functions.php, он исчезнет при смене темы. Для системного ограничения используйте mu-plugin или отдельный мини-плагин.
Заблокировали не только xmlrpc.php, но и нужные запросы
Иногда администраторы копируют слишком жесткие правила в nginx или .htaccess и случайно ломают соседние правила. После правки всегда проверяйте, что сайт открывается, а не только что xmlrpc.php недоступен.
Путают XML-RPC и REST API
Это разные механизмы. Если вы закрыли XML-RPC, редактор Gutenberg и большинство современных плагинов продолжат работать. Если же вы начнете ограничивать REST API, последствия будут совсем другими.
Практические советы по безопасности и производительности
Если XML-RPC вам не нужен, отключение — нормальная мера. Она уменьшает поверхность атаки и убирает лишний endpoint, который часто используют для брутфорса. Но не стоит считать это полной защитой: парольная политика, обновления ядра, тем и плагинов, а также ограничение попыток входа остаются важны.
На сайтах с высокой нагрузкой блокировка на уровне веб-сервера предпочтительнее, чем обработка запроса внутри WordPress. Так вы не тратите ресурсы PHP на заведомо лишние обращения.
Если вам нужен более широкий контроль над дублями, индексированием и технической чисткой сайта, иногда удобнее собрать это в одном инструменте, чем держать набор разрозненных правок. В экосистеме WPShop для таких задач есть Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wp-box.ru&utm_medium=article&utm_campaign=kak-otklyuchit-xmlrpc-i-zashchitit-sayt-ot-bruteforce
Но даже с плагином важно понимать, что именно он меняет. Любая автоматизация должна быть проверяема через логи, тестовый прогон и откатный план.