XML-RPC в WordPress часто держат включённым «на всякий случай», а потом удивляются лишним запросам, попыткам брутфорса и странным обращениям к /xmlrpc.php. При этом отключать его вслепую тоже нельзя: у некоторых старых клиентов, мобильных приложений и внешних сервисов он всё ещё используется.
Ниже — рабочий сценарий: как понять, нужен ли вам XML-RPC, чем его лучше отключать, как проверить результат и где чаще всего ломают сайт после таких правок.
Когда XML-RPC действительно стоит отключить
Если у вас обычный сайт на WordPress, а публикация идёт через админку или через REST API, XML-RPC чаще всего не нужен. Особенно если в логах видно много обращений к xmlrpc.php с разных IP, а в панели безопасности или на хостинге растёт число подозрительных запросов.
Но есть сценарии, где он ещё может быть полезен:
- старые приложения для публикации записей;
- некоторые внешние сервисы, которые подключаются не через REST API;
- устаревшие интеграции с мобильными клиентами WordPress;
- редкие случаи, когда нужен pingback/trackback, хотя на практике это почти всегда лишнее.
Диагностика: нужен ли вам XML-RPC прямо сейчас
Начните не с отключения, а с проверки факта использования. Посмотрите логи веб-сервера, отчёты WAF или плагина безопасности. Если в запросах к /xmlrpc.php нет легитимных обращений от ваших сервисов, риск минимален.
Полезно проверить и сам сайт вручную: если вы не используете внешние клиенты для публикации, не подключали старые мобильные приложения и не знаете, зачем вам pingback, почти наверняка XML-RPC можно отключать.
Как отключить XML-RPC безопасно
Есть три нормальных подхода: через плагин, через код и на уровне сервера. Выбор зависит от того, насколько у вас управляемый хостинг и нужен ли быстрый откат.
| Способ | Плюсы | Минусы |
|---|---|---|
| Плагин безопасности | Быстро, без правки кода, удобно для админов | Лишняя зависимость от плагина |
Код в functions.php или mu-plugin | Прозрачно, легко контролировать в репозитории | Нужно аккуратно обновлять тему или выносить в отдельный файл |
| Правило на сервере | Снимает нагрузку раньше WordPress | Зависит от доступа к nginx/apache и навыков администрирования |
Вариант 1: отключить через код
Если нужен предсказуемый и переносимый вариант, добавьте фильтр в functions.php дочерней темы или, лучше, в отдельный mu-plugin. Для большинства сайтов этого достаточно.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
Если хотите не просто отключить XML-RPC, а ещё и отдать корректный ответ на прямой запрос к файлу, можно добавить блокировку через init. Это не обязательно, но иногда полезно, если сторонние сканеры продолжают долбить xmlrpc.php.
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
}
} );
Такой код лучше держать не в основной теме, а в mu-plugin: тогда он не исчезнет после смены дизайна.
Вариант 2: отключить через плагин
Если на сайте уже есть плагин безопасности или оптимизации, проверьте его настройки. У многих решений есть отдельная опция для XML-RPC. Это удобно, когда вы не хотите плодить код в теме и предпочитаете управлять защитой из админки.
Из практики: если на сайте уже стоит плагин для чистки и SEO-настроек, например Clearfy Pro, отключение XML-RPC можно держать в одном месте вместе с другими техническими правками. Но всё равно проверьте, не конфликтует ли эта опция с другими модулями безопасности.
Вариант 3: блокировка на уровне сервера
Если у вас есть доступ к конфигу nginx или Apache, можно закрыть xmlrpc.php ещё до загрузки WordPress. Это полезно на нагруженных сайтах: лишний PHP-запуск не происходит вообще.
Для nginx пример может выглядеть так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>
Но здесь важно не переусердствовать: если сайт обслуживается через нестандартную схему, сначала проверьте, что правило действительно применяется, а не ломает другие обработчики.
Как проверить, что отключение сработало
После внедрения не ограничивайтесь «в админке всё открывается». Нужно проверить именно точку атаки и возможные интеграции.
- Откройте
/xmlrpc.phpв браузере — он не должен отдавать рабочий XML-RPC-ответ. - Проверьте логи сервера: обращения к этому файлу должны либо исчезнуть, либо получать 403.
- Если у вас был внешний клиент публикации, попробуйте отправить тестовый пост или подключение.
- Проверьте, не появились ли ошибки в логах PHP и веб-сервера после правки.
Если используете мониторинг безопасности, посмотрите, уменьшилось ли число попыток обращения к XML-RPC. Это не «магическая метрика», но хороший индикатор того, что точка входа закрыта.
Частые ошибки после отключения XML-RPC
Ломают старую интеграцию и не замечают сразу
Самая частая проблема — отключили XML-RPC, а потом через неделю выяснилось, что один из сервисов публикации всё ещё ходил именно туда. Поэтому перед изменением нужно хотя бы один раз пройтись по списку внешних подключений: мобильные клиенты, автопостинг, старые CRM и сервисы синхронизации.
Добавляют код в активную тему
Если правка лежит в functions.php основной темы, она исчезнет после обновления или смены шаблона. Для технических ограничений лучше использовать mu-plugin или отдельный мини-плагин. Это особенно важно на проектах, где тема меняется чаще, чем логика сайта.
Путают отключение XML-RPC с отключением REST API
Это разные механизмы. Если вам нужен мобильный редактор, интеграции с внешними сервисами или современная автоматизация, REST API может быть нужен, даже если XML-RPC уже закрыт. Не стоит выключать всё подряд только ради «безопасности».
Ставят сразу несколько блокировок
Иногда админ включает фильтр в WordPress, правило в nginx, ещё одно в плагине безопасности и получает трудно диагностируемую ошибку. Если что-то не работает, сначала оставьте один понятный способ блокировки и проверьте его отдельно.
Что делать, если XML-RPC нужен частично
Иногда полностью отключать его нельзя, но и держать открытым без ограничений не хочется. Тогда лучше не искать «волшебный» универсальный плагин, а ограничить поверхность атаки другими мерами: сложные пароли, двухфакторная аутентификация, ограничение логинов, защита от перебора, WAF на хостинге.
Если интеграция старая и её нельзя быстро перевести на REST API, зафиксируйте это как технический долг. В таких случаях полезно хотя бы документировать, какой сервис использует XML-RPC и почему его пока нельзя убрать.
Проверка после внедрения: короткий чек-лист
/xmlrpc.phpне отвечает как рабочий endpoint;- легитимные интеграции не сломались;
- в логах нет новых PHP-ошибок;
- правило отключения лежит в месте, которое не потеряется при обновлении темы;
- на сервере нет дублирующих конфликтующих блокировок.
Если нужен более широкий технический аудит сайта, имеет смысл смотреть не только на XML-RPC, но и на дубли, мусорные запросы, индексацию и общую чистку технических настроек. Для этого часто удобнее держать отдельный набор SEO/технических правок в одном месте, а не размазывать их по теме и нескольким плагинам.