XML-RPC в WordPress часто отключают по одной причине: через этот интерфейс удобно брутфорсить логин и дергать сайт лишними запросами. Но у него есть и легитимные сценарии — мобильное приложение WordPress, старые внешние публикации, некоторые интеграции с сервисами автопостинга. Поэтому задача не в том, чтобы «вырубить всё», а в том, чтобы понять, нужен ли вам этот канал вообще, и если нужен — ограничить его аккуратно.
Ниже разберем, как диагностировать использование XML-RPC, чем отличается блокировка на уровне кода, сервера и плагина, и как проверить, что после изменений не отвалились нужные подключения.
Когда XML-RPC реально стоит отключать
Если сайт не использует старое мобильное приложение WordPress, внешние клиенты публикации и интеграции, которые ходят именно через xmlrpc.php, то этот endpoint чаще всего только добавляет поверхность атаки. На практике его оставляют включенным по инерции, а потом удивляются лишним запросам в логах и попыткам подбора пароля.
Отключение особенно уместно, если:
- в логах есть регулярные запросы к
/xmlrpc.php; - на сайте нет внешних сервисов, которым нужен XML-RPC;
- вы публикуете контент только через админку WordPress или REST API;
- хостинг или WAF не закрывают этот endpoint на уровне сервера.
Что может сломаться после отключения
Самый частый риск — не сам сайт, а внешняя интеграция. Например, приложение на телефоне перестанет публиковать записи, а старый скрипт автопостинга начнет получать ошибку авторизации. Если вы не уверены, сначала проверьте, кто вообще обращается к XML-RPC, и только потом режьте доступ.
Диагностика: как понять, используется ли xmlrpc.php
Начните с логов веб-сервера. Если у вас есть доступ к access log, ищите обращения к xmlrpc.php. Это самый надежный способ понять, есть ли живые запросы, а не просто теоретическая возможность.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если логов нет под рукой, можно проверить endpoint вручную. Откройте в браузере https://example.com/xmlrpc.php. Нормальный ответ WordPress обычно выглядит как сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не означает, что всё безопасно, но подтверждает, что endpoint доступен.
Еще один практичный тест — временно отправить POST-запрос и посмотреть ответ сервера. Если вы отключите XML-RPC позже, этот же запрос должен начать возвращать 403, 404 или иной отказ в зависимости от способа блокировки.
curl -i -X POST https://example.com/xmlrpc.phpКак отключить XML-RPC: сравнение подходов
Есть три рабочих варианта. Выбор зависит от того, где вам удобнее управлять доступом и нужен ли вам гибкий контроль.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин | Нужна быстрая настройка без кода | Просто включить, легко откатить | Лишняя зависимость, не всегда закрывает endpoint на уровне сервера |
| Код в теме или mu-plugin | Нужен контроль без сторонних плагинов | Прозрачно, можно точечно управлять | Требует аккуратного размещения и теста после обновлений |
| Правило на сервере | Есть доступ к nginx/apache и нужно отрезать запросы раньше WordPress | Меньше нагрузки, быстрее блокировка | Нужен доступ к конфигу и понимание окружения |
Пошаговое решение через код
Если вы хотите отключить XML-RPC без плагина, самый безопасный вариант — добавить небольшой mu-plugin. Так правило не потеряется при смене темы и не зависит от активной темы оформления.
Создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте ее вручную.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот фильтр отключает XML-RPC штатно, без правок ядра. Для большинства сайтов этого достаточно.
Если вам нужно не просто отключить функциональность, а вернуть 403 на сам запрос к xmlrpc.php, можно добавить более жесткую блокировку через template_redirect. Но здесь есть нюанс: WordPress уже должен загрузиться, то есть запрос все равно дойдет до PHP. Это нормально для небольших сайтов, но не лучший вариант, если вы хотите отрезать endpoint раньше.
<?php
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );На практике чаще хватает первого варианта. Второй полезен, если у вас есть особые требования к ответу сервера или вы хотите явно фиксировать отказ.
Отключение на уровне nginx или Apache
Если у вас есть доступ к конфигу веб-сервера, блокировать xmlrpc.php лучше там. Так запрос не будет доходить до WordPress вообще.
nginx
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Это жесткий и понятный вариант. Если позже понадобится вернуть доступ, достаточно убрать правило.
Apache
<Files "xmlrpc.php">
Require all denied
</Files>Для Apache это стандартный способ закрыть конкретный файл. Важно размещать правило там, где оно реально применяется к сайту, а не в абстрактном конфиге, который хостинг игнорирует.
Если нужен не полный запрет, а ограничение
Иногда XML-RPC нужен только для одного сценария, например для внешнего клиента публикации. В таком случае не стоит сразу рубить endpoint полностью. Лучше сначала проверить, можно ли заменить интеграцию на REST API или штатную авторизацию WordPress.
Если замена невозможна, ограничьте доступ на уровне сети или WAF: по IP, по стране, по базовым сигнатурам атак. Это не идеальная защита, но она лучше, чем открытый endpoint без контроля.
- оставьте XML-RPC только для доверенных IP, если интеграция статична;
- проверьте, не использует ли сервис альтернативный API;
- не включайте «защиту» через скрытие файла — это не защита, а иллюзия.
Проверка результата после внедрения
После отключения проверьте три вещи: ответ endpoint, логи и рабочие интеграции. Без этого легко получить ложное ощущение безопасности.
- Откройте
/xmlrpc.phpв браузере или черезcurl. - Убедитесь, что ответ больше не 200/405 с сообщением WordPress.
- Посмотрите access log: новые запросы должны либо отсутствовать, либо получать отказ.
- Проверьте мобильное приложение WordPress и внешние сервисы, если они у вас есть.
Простой тест через curl после блокировки:
curl -i -X POST https://example.com/xmlrpc.phpЕсли вы закрыли endpoint на сервере, ожидайте 403. Если через фильтр WordPress — поведение может отличаться в зависимости от конфигурации, но запрос не должен проходить как рабочий.
Частые ошибки и как их исправить
Отключили XML-RPC в плагине, но endpoint все равно отвечает
Так бывает, если плагин только ограничивает отдельные функции, а не блокирует сам файл на уровне сервера. Решение — добавить правило в nginx/Apache или использовать mu-plugin с xmlrpc_enabled.
Сломалось мобильное приложение WordPress
Значит, оно действительно использовало XML-RPC. Проверьте, можно ли перейти на REST API или отказаться от этого канала. Если нет — не отключайте endpoint полностью, а ограничьте доступ точечно.
Поставили правило в теме, а потом оно исчезло после обновления
Это типичная ошибка. Код для безопасности не должен жить в теме, если он не связан с отображением. Используйте mu-plugin или отдельный мини-плагин.
Закрыли файл, но забыли про кэш и WAF
Иногда старые ответы продолжают отдаваться из промежуточного кэша, а WAF показывает свои собственные страницы ошибки. После изменения правил очистите кэш на стороне сайта и, если нужно, на стороне CDN.
Что еще проверить для безопасности и производительности
Отключение XML-RPC само по себе не делает сайт защищенным, но убирает один из лишних входов. Имеет смысл сразу проверить соседние точки риска: актуальность ядра, ограничение попыток входа, наличие ненужных публичных endpoint'ов, а также логи на предмет повторяющихся атак.
Если у вас много технических правок в WordPress, удобно держать такие изменения в отдельном mu-plugin и не смешивать их с темой. Это упрощает поддержку и снижает шанс случайно потерять защиту после редизайна.
Для сайтов, где регулярно приходится чистить SEO-дубли, закрывать лишние архивы и убирать технический мусор, полезно иметь единый набор правил в одном месте. В таких задачах часто выручает Clearfy Pro, если вам нужен набор практических SEO- и технических настроек без ручного разбрасывания по нескольким плагинам.
Главный критерий простой: если после отключения XML-RPC сайт продолжает работать как раньше, а в логах больше нет лишних обращений к xmlrpc.php, значит решение внедрено правильно. Если что-то отвалилось — не возвращайте endpoint «на всякий случай», а сначала найдите конкретную интеграцию, которая его использует.