Если на сайте включён Jetpack, мобильные приложения WordPress или сторонние сервисы публикации, полный запрет xmlrpc.php часто оказывается слишком грубым решением. Но и оставлять этот файл открытым для всех подряд — плохая идея: именно его обычно проверяют боты на предмет перебора логинов и лишнего шума в логах.
Рабочий сценарий здесь не «выключить всё», а ограничить доступ к XML-RPC по задаче: либо убрать его для обычных посетителей и ботов, либо оставить только там, где он реально нужен. Ниже — как понять, что именно у вас используется, чем отличается блокировка на уровне сервера от блокировки в WordPress, и как проверить, что после правки ничего не сломалось.
Когда XML-RPC действительно нужен
Сначала стоит проверить, есть ли у сайта зависимость от XML-RPC. На практике он нужен не всем, но если вы пользуетесь одним из этих сценариев, полный запрет может создать проблемы:
- Jetpack подключается к сайту и синхронизирует данные;
- публикация или редактирование записей идёт из мобильного приложения WordPress;
- используются внешние сервисы, которые отправляют записи через XML-RPC;
- настройки старых интеграций завязаны на
xmlrpc.php, а не на REST API.
Если ничего из этого не используется, проще закрыть доступ полностью. Если используется хотя бы один пункт, лучше сначала проверить журнал ошибок и поведение интеграций на тестовой копии.
Диагностика: как понять, кто обращается к xmlrpc.php
Самый быстрый способ — посмотреть access log веб-сервера. Ищите запросы к /xmlrpc.php и частоту обращений. Если там в основном POST с одинаковых IP и без полезной нагрузки, это типичный шум от ботов.
Что искать в логах
- повторяющиеся запросы с одного адреса;
- много
POSTкxmlrpc.phpбез успешных ответов; - ошибки авторизации или ответы
403/405после попыток вызова методов; - рост нагрузки на PHP без видимой пользы для сайта.
Если доступа к логам нет, можно временно включить мониторинг на уровне хостинга или проверить, не появляются ли ошибки в Jetpack после ограничений. Это особенно важно, если сайт работает на общем хостинге и вы не хотите случайно заблокировать легитимные запросы.
Пошаговое решение: закрыть XML-RPC для лишних запросов
Есть три практических варианта: блокировка на уровне сервера, фильтрация в WordPress и точечное ограничение по IP. Выбор зависит от того, нужен ли вам XML-RPC вообще.
| Подход | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Блокировка на сервере | XML-RPC не нужен совсем | Не тратит ресурсы PHP | Может затронуть интеграции, если забыть о них |
| Фильтр в WordPress | Нужен контроль из кода | Гибко и прозрачно | Запрос уже доходит до PHP |
| Ограничение по IP | Есть конкретные доверенные адреса | Точечный доступ | Сложнее поддерживать |
Вариант 1: запретить доступ на уровне Nginx
Если XML-RPC не нужен вообще, лучше отрезать его до PHP. Для Nginx это выглядит так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После этого запросы к файлу будут сразу получать отказ, а PHP не будет запускаться. Это самый чистый вариант с точки зрения производительности.
Вариант 2: запретить доступ на уровне Apache
Для Apache можно использовать правило в .htaccess или конфиге виртуального хоста:
<Files xmlrpc.php>
Require all denied
</Files>Если сайт работает через старую схему с AllowOverride, проверьте, что правило действительно применяется. Иначе вы увидите ложное ощущение защиты, а файл останется доступным.
Вариант 3: отключить XML-RPC через WordPress-фильтр
Если нужен более мягкий контроль, можно отключить XML-RPC из темы или, лучше, через мини-плагин. Это полезно, когда вы хотите управлять поведением без правок серверной конфигурации.
<?php
/**
* Plugin Name: Disable XML-RPC for guests
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключит XML-RPC целиком. Он прост, но не подходит, если Jetpack или мобильное приложение должны продолжать работать.
Вариант 4: оставить доступ только для доверенных IP
Если у вас есть конкретный сервис или офисный IP, можно ограничить доступ на уровне сервера. Для Nginx это обычно делается через allow и deny:
location = /xmlrpc.php {
allow 203.0.113.10;
allow 203.0.113.11;
deny all;
}Такой подход уместен, когда XML-RPC нужен только для одного внешнего источника. Если адреса часто меняются, поддерживать список вручную неудобно, и лучше перейти на другой способ интеграции.
Как не сломать Jetpack и мобильные приложения
Главная ошибка — закрыть xmlrpc.php и потом искать причину, почему Jetpack перестал синхронизироваться или приложение WordPress не публикует записи. Поэтому после изменения правил нужно проверить именно те функции, которые завязаны на XML-RPC.
- откройте Jetpack и проверьте статус соединения;
- попробуйте создать черновик из мобильного приложения WordPress;
- если используется удалённая публикация, выполните тестовый запрос;
- посмотрите, нет ли новых ошибок в журнале сервера или в
debug.log.
Если интеграция сломалась, не пытайтесь «разрешить всё обратно» без разбора. Лучше выяснить, какой именно сервис обращается к XML-RPC, и ограничить только его.
Проверка результата после внедрения
После настройки нужно убедиться в двух вещах: файл действительно закрыт для лишних запросов, а нужные сценарии продолжают работать.
Проверка снаружи
Самый простой тест — открыть /xmlrpc.php в браузере или отправить запрос через curl. Если доступ закрыт на сервере, вы должны увидеть отказ в доступе или пустой ответ без выполнения PHP-логики.
curl -I https://example.com/xmlrpc.phpОжидаемое поведение зависит от выбранного способа блокировки: это может быть 403 Forbidden, 404 Not Found или другой отказ, но не обычный ответ XML-RPC с признаками активной обработки.
Проверка интеграций
Дальше проверьте:
- подключение Jetpack;
- публикацию из мобильного приложения WordPress;
- внешние сервисы, если они у вас есть;
- отсутствие новых ошибок авторизации в логах.
Если всё работает, а лишние запросы больше не доходят до PHP, задача решена корректно.
Частые ошибки и как их исправить
Полностью отключили XML-RPC, хотя он нужен
Это самая частая проблема. Симптомы обычно проявляются не сразу: Jetpack теряет связь, приложение не публикует записи, а внешняя интеграция начинает сыпать ошибками. Решение — вернуть доступ и перейти на ограничение по IP или на серверное правило только для нежелательных источников.
Добавили правило не в тот слой
Иногда правило пишут в .htaccess, но сайт работает на Nginx без Apache, либо наоборот. В результате файл остаётся доступным. Проверяйте, какой веб-сервер реально обслуживает сайт, и вносите правило туда, где оно будет исполнено.
Ожидали, что WordPress сам «не будет отвечать»
Фильтр xmlrpc_enabled отключает функциональность на уровне WordPress, но запрос всё равно доходит до PHP. Если ваша цель — снизить нагрузку и убрать шум в логах, лучше блокировать доступ раньше, на уровне сервера.
Забыли про кэш и проверили старую страницу
После изменения правил иногда мешает кэш на стороне CDN или хостинга. Если тест показывает старое поведение, очистите кэш и повторите проверку напрямую, минуя промежуточные слои.
Что делать, если нужен только один способ доступа
Если XML-RPC нужен для конкретной интеграции, но вы не хотите оставлять его открытым для всех, выбирайте минимально достаточный доступ. На практике это либо whitelist по IP, либо отдельная среда для интеграции, либо переход на REST API, если сервис это поддерживает.
Для сайтов, где важна общая техническая чистота, полезно держать под рукой инструменты, которые помогают убирать лишние точки входа и дубли поведения. Если вы уже используете Clearfy Pro, часть таких задач можно закрывать централизованно, но правила для xmlrpc.php всё равно лучше проверять вручную на уровне сервера.
Короткий чек-лист перед публикацией правки
- Поняли, нужен ли XML-RPC вообще.
- Проверили логи на обращения к
xmlrpc.php. - Выбрали способ блокировки: сервер, WordPress или IP-ограничение.
- Проверили Jetpack и мобильное приложение WordPress.
- Убедились, что лишние запросы больше не доходят до PHP.
- Очистили кэш и повторили тест снаружи.
Если после этого сайт работает штатно, а xmlrpc.php больше не используется случайными клиентами и ботами, значит ограничение настроено правильно и без лишнего риска для админки.