Файл xmlrpc.php до сих пор часто оставляют открытым по умолчанию, хотя на большинстве сайтов он не нужен. Проблема в том, что через него идут лишние запросы, попытки подбора паролей и нагрузка от ботов. При этом просто удалить файл нельзя: в некоторых сценариях он используется для мобильного приложения WordPress, внешних публикаций и старых интеграций.
Ниже разберём, как понять, нужен ли вам xmlrpc.php, как закрыть к нему доступ на уровне сервера или WordPress, и как проверить, что после изменений ничего не сломалось.
Когда xmlrpc.php действительно мешает
На практике этот файл становится проблемой в трёх случаях: на сайт идёт много запросов к /xmlrpc.php, в логах появляются повторяющиеся попытки авторизации, либо хостинг показывает лишнюю нагрузку без видимой причины. Часто это не атака в классическом смысле, а массовый брутфорс или сканирование ботами. Если сайт не использует внешние клиенты публикации и не подключён к старым сервисам, закрытие доступа обычно безопасно.
Что проверить перед отключением
- Используете ли вы мобильное приложение WordPress для публикации.
- Есть ли внешние сервисы, которые отправляют записи через XML-RPC.
- Не завязан ли на XML-RPC старый плагин синхронизации или автопостинга.
- Есть ли в логах обращения к
/xmlrpc.phpот реальных пользователей или только от ботов.
Диагностика проблемы: как понять, что запросы идут именно сюда
Самый простой способ — посмотреть access log веб-сервера. Если у вас Nginx или Apache, ищите строки с /xmlrpc.php. Обычно там видно частые POST-запросы с одинаковых IP или с разных адресов, но по одному и тому же шаблону. Если доступа к логам нет, можно временно поставить правило в плагине безопасности или на уровне сервера и посмотреть, не появятся ли жалобы от пользователей.
Для быстрой проверки можно использовать и команду curl снаружи сайта:
curl -I https://example.com/xmlrpc.phpЕсли файл открыт, сервер обычно отвечает не 404, а 200 или 405. Это не означает уязвимость само по себе, но показывает, что точка входа доступна.
Как закрыть xmlrpc.php: рабочие варианты
Есть три нормальных подхода: блокировка на сервере, отключение через WordPress-фильтр и использование плагина безопасности. Выбор зависит от того, есть ли у вас доступ к конфигу веб-сервера и нужен ли XML-RPC хотя бы частично.
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Серверный блок | Есть доступ к Nginx/Apache | Самый надёжный и дешёвый по ресурсам | Нужно править конфиг |
| Фильтр в WordPress | Нет доступа к серверу | Быстро внедряется | Запрос всё равно доходит до WordPress |
| Плагин безопасности | Нужен интерфейс без кода | Удобно для админов | Дополнительная зависимость |
Вариант 1: блокировка в Nginx
Если сайт работает на Nginx, можно сразу отдавать 403 на запросы к xmlrpc.php. Это не даёт запросу попасть в WordPress и снижает нагрузку.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации проверьте синтаксис и перезагрузите сервер. Для Nginx это обычно выглядит так:
nginx -t
systemctl reload nginxВариант 2: блокировка в Apache
Если используется Apache, можно закрыть файл через .htaccess. Это не так эффективно, как серверный конфиг, но для большинства типовых установок работает нормально.
<Files xmlrpc.php>
Require all denied
</Files>Если у вас старая версия Apache, иногда встречается синтаксис через Order и Deny, но на современных установках лучше использовать Require all denied.
Вариант 3: отключение через WordPress-код
Если доступ к серверу ограничен, можно отключить XML-RPC через фильтр xmlrpc_enabled. Это рабочий вариант, но он не заменяет серверную блокировку, если цель — именно снизить нагрузку от ботов.
<?php
add_filter('xmlrpc_enabled', '__return_false');Такой код можно добавить в functions.php дочерней темы или в собственный мини-плагин. Если потом понадобится вернуть доступ, достаточно убрать фильтр.
Пошаговое решение без лишнего риска
- Проверьте, нужен ли вам XML-RPC для реальных сценариев.
- Сделайте резервную копию конфигурации или файла, который будете менять.
- Выберите один способ блокировки: сервер, WordPress или плагин.
- Внесите изменение только в одном месте, чтобы не получить двойную блокировку и путаницу при отладке.
- Проверьте ответ
/xmlrpc.phpснаружи сайта. - Посмотрите логи и убедитесь, что обращения больше не проходят.
Как проверить, что решение сработало
Проверка должна быть не формальной, а практической. Откройте https://ваш-домен/xmlrpc.php в браузере или выполните curl -I. При серверной блокировке вы должны увидеть 403 Forbidden или 404 Not Found в зависимости от выбранной схемы. Если вы отключали XML-RPC через WordPress-фильтр, ответ может быть другим, но главное — отсутствие возможности выполнить XML-RPC-методы.
Дополнительно проверьте:
- не перестали ли работать мобильные клиенты WordPress, если вы их используете;
- не сломалась ли внешняя публикация из стороннего сервиса;
- не выросло ли число ошибок в логах после внедрения;
- не остались ли дублирующие правила в плагине безопасности и на сервере.
Частые ошибки и как их исправить
Закрыли xmlrpc.php, но забыли про реальные интеграции
Это типичная ситуация, когда после блокировки перестаёт работать приложение для публикации или старый сервис автопостинга. Решение простое: сначала выяснить, кто использует XML-RPC, и только потом резать доступ. Если интеграция нужна, лучше ограничить её по IP или перенести на REST API.
Поставили сразу несколько способов блокировки
Например, добавили правило в .htaccess, включили плагин безопасности и ещё фильтр в теме. В итоге непонятно, что именно ломает запрос. Оставьте один основной способ и документируйте его в комментарии к конфигу.
Ожидали, что WordPress перестанет отвечать на любые запросы
Фильтр xmlrpc_enabled отключает XML-RPC на уровне WordPress, но сам файл остаётся доступен как точка входа. Если нужна именно жёсткая защита от сканирования и лишней нагрузки, используйте блокировку на сервере.
Проверяли только из админки
Некоторые плагины показывают, что защита включена, но это не заменяет внешний тест. Проверяйте ответ снаружи сайта, потому что именно так его видят боты и сканеры.
Практические советы по безопасности и производительности
Если сайт не использует XML-RPC, лучше закрыть его на уровне сервера и зафиксировать это в документации проекта. Это уменьшает поверхность атаки и убирает лишние запросы до WordPress. Если у вас много технических правок в одном проекте, удобно держать такие настройки в отдельном файле деплоя или в конфигурации виртуального хоста, а не размазывать по теме.
Для сайтов, где важно быстро убирать лишние технические хвосты, иногда имеет смысл использовать инструменты вроде Clearfy Pro, если вам нужен набор функций для чистки и технической оптимизации. Но саму блокировку xmlrpc.php всё равно лучше делать там, где она будет работать предсказуемо: на сервере или в собственном коде.
Если после отключения XML-RPC вы видите меньше мусорных запросов и не теряете нужные интеграции, значит решение выбрано правильно. Если что-то перестало публиковаться, не возвращайте доступ полностью — сначала найдите конкретный сервис и ограничьте его отдельно.