XML-RPC в WordPress часто отключают «на всякий случай», а потом удивляются, почему перестало работать мобильное приложение, внешняя публикация или старый сервис синхронизации. На практике задача не в том, чтобы просто заблокировать файл xmlrpc.php, а в том, чтобы понять, используется ли он вообще, и закрыть только лишний вход.
Если сайт не интегрирован со сторонними сервисами через XML-RPC, отключение обычно оправдано: это убирает лишнюю поверхность атаки и снижает шум от запросов к xmlrpc.php. Но если у вас есть Jetpack, внешняя публикация через старые клиенты или синхронизация с мобильным приложением WordPress, сначала проверьте зависимости.
Когда XML-RPC можно отключать
Сначала ответьте на простой вопрос: кто и зачем обращается к xmlrpc.php? Если ответ «никто», отключение — нормальная техническая мера. Если ответ «не уверен», сначала проверьте логи веб-сервера и список подключённых сервисов.
Что обычно использует XML-RPC
- Jetpack и некоторые его функции;
- старые мобильные клиенты WordPress;
- внешняя публикация через сторонние редакторы и интеграции;
- некоторые сервисы мониторинга и автопостинга.
Диагностика проблемы: как понять, нужен ли файл xmlrpc.php
Самый надёжный способ — посмотреть реальные обращения. В access.log ищите запросы к /xmlrpc.php. Если там только попытки подбора паролей и боты, а легитимных запросов нет, отключение безопасно.
Если доступ к логам есть не у всех, можно временно включить наблюдение на уровне сервера или использовать плагин безопасности, который показывает частоту обращений. Но не полагайтесь только на «ощущение»: XML-RPC часто не заметен до тех пор, пока не сломается внешняя интеграция.
Чек-лист перед отключением
- Проверить, используется ли Jetpack;
- проверить мобильное приложение WordPress у редакторов;
- проверить внешние сервисы автопубликации;
- посмотреть access.log на обращения к
xmlrpc.php; - сделать резервную копию конфигурации и файлов.
Как отключить XML-RPC: рабочие варианты
Есть три практических подхода: через код, через веб-сервер и через плагин безопасности. Выбор зависит от того, где вам удобнее контролировать правило.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Контроль в WordPress, легко откатить | Файл всё ещё доступен на уровне веб-сервера |
| Правило в Nginx/Apache | Запросы режутся раньше, меньше нагрузки | Нужен доступ к конфигу сервера |
| Плагин безопасности | Быстро включить без правок кода | Лишняя зависимость от плагина |
Вариант 1: отключить XML-RPC через код
Это удобно, если вы управляете сайтом через тему или небольшой mu-plugin. Код ниже отключает обработку XML-RPC на уровне WordPress.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если нужен более жёсткий вариант, можно дополнительно убрать заголовок X-Pingback и не давать WordPress объявлять поддержку pingback.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
add_filter( 'wp_headers', function( $headers ) {
if ( isset( $headers['X-Pingback'] ) ) {
unset( $headers['X-Pingback'] );
}
return $headers;
} );Этот способ не ломает сайт сам по себе, но не блокирует прямой HTTP-запрос к файлу на уровне сервера. Для большинства сайтов этого достаточно, если цель — убрать функциональность внутри WordPress.
Вариант 2: заблокировать xmlrpc.php на уровне Nginx
Если у вас Nginx, лучше отсечь запросы раньше, чем они попадут в PHP. Это уменьшает лишнюю нагрузку и убирает сам факт обращения к файлу.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации проверьте синтаксис и перезагрузите Nginx. Не вносите правило в случайный include-файл, если не понимаете цепочку подключений.
Вариант 3: блокировка через Apache
Для Apache обычно используют .htaccess. Это не самый изящный вариант, но он рабочий, если нет доступа к основному конфигу.
<Files xmlrpc.php>
Require all denied
</Files>Если сайт работает через старую схему с Order allow,deny, не смешивайте синтаксис разных версий Apache в одном блоке. Это частая причина, почему правило не срабатывает.
Как проверить, что отключение сработало
Проверка должна быть не «страница открывается», а именно «XML-RPC больше не отвечает». Самый простой тест — открыть /xmlrpc.php в браузере или через curl.
curl -I https://example.com/xmlrpc.phpОжидаемое поведение зависит от способа блокировки: либо 403 Forbidden, либо пустой/ошибочный ответ без доступного XML-RPC-метода. Если вы отключали только фильтром WordPress, файл может продолжать существовать, но запросы к методам должны не выполняться.
Дополнительно проверьте:
- не работает ли публикация из внешнего клиента;
- не ругается ли Jetpack на потерю связи;
- не появились ли ошибки в error.log после изменения правил;
- не изменился ли статус сайта в сервисах мониторинга.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом сломался Jetpack
Это типичный сценарий. Jetpack использует XML-RPC для части функций, поэтому перед блокировкой проверьте, какие модули реально нужны. Если Jetpack обязателен, не режьте xmlrpc.php полностью, а пересмотрите набор подключённых функций.
Правило добавили, но файл всё ещё отвечает
Значит, правило не там, где нужно. В Nginx проверьте, что блок действительно попал в активный server. В Apache убедитесь, что .htaccess читается и AllowOverride не отключён. В WordPress-коде проверьте, что файл с фильтром вообще загружается.
Сайт начал отдавать 500 после правки
Обычно причина в синтаксической ошибке или конфликте с уже существующим правилом. Откатите последнее изменение и проверьте конфиг через штатные средства: nginx -t для Nginx или лог Apache для ошибок конфигурации.
Отключили XML-RPC, но боты всё равно стучатся
Это нормально: они продолжают пробовать. Важен не сам факт попыток, а то, что запросы не доходят до WordPress и не создают нагрузку. Если атак слишком много, дополнительно смотрите в сторону rate limiting на уровне сервера или WAF.
Безопасность и производительность: что ещё стоит учесть
Отключение XML-RPC полезно только как часть общей гигиены. Если на сайте слабые пароли, открытая регистрация и устаревшие плагины, один закрытый файл проблему не решит.
- держите WordPress, тему и плагины в актуальном состоянии;
- ограничьте доступ к админке по IP, если это возможно;
- используйте двухфакторную аутентификацию для администраторов;
- проверяйте логи на повторяющиеся запросы к
xmlrpc.phpиwp-login.php; - не ставьте несколько плагинов, которые делают одно и то же отключение одновременно.
Если вам нужен более широкий набор мер по чистке сайта и удалению лишних технических сущностей, удобно смотреть в сторону комплексных инструментов вроде Clearfy Pro, но только если вам реально нужен набор функций, а не ещё один слой настроек. Подробности есть на странице плагина.
Когда лучше не отключать XML-RPC полностью
Если сайт живёт на внешних интеграциях, а вы не готовы быстро проверить каждую из них, не рубите доступ вслепую. В таком случае сначала ограничьте доступ на уровне сервера, посмотрите логи и только потом принимайте решение. Для рабочих проектов это безопаснее, чем «сломать, а потом искать, что именно перестало работать».
Практический ориентир простой: если после теста curl и проверки интеграций ничего не отвалилось, правило можно оставлять. Если что-то перестало публиковаться или синхронизироваться, ищите конкретный сервис, а не возвращайте XML-RPC целиком без анализа.