Файл xmlrpc.php в WordPress часто отключают по двум причинам: чтобы снизить поверхность атаки и убрать лишние запросы, которые создают нагрузку на сайт. Но закрывать его «в лоб» не всегда безопасно: если у вас подключён Jetpack, мобильное приложение WordPress или внешняя публикация через XML-RPC, сайт начнёт терять часть функций.
Ниже разберём, как понять, нужен ли вам этот файл, чем его лучше закрывать и как проверить, что после изменений ничего не сломалось.
Когда xmlrpc.php действительно стоит закрыть
Если сайт не использует удалённую публикацию, pingback’и и сторонние сервисы, которым нужен XML-RPC, доступ к xmlrpc.php можно ограничить. На практике это полезно, когда в логах видно много запросов к этому файлу, а в панели безопасности регулярно всплывают попытки подбора логина через XML-RPC.
Но перед изменениями проверьте, есть ли у вас зависимости:
- Jetpack и некоторые его функции;
- мобильное приложение WordPress;
- старые внешние клиенты для публикации;
- интеграции, которые отправляют данные через XML-RPC.
Быстрая диагностика проблемы
Посмотрите логи веб-сервера или отчёты хостинга. Если xmlrpc.php постоянно запрашивают с разных IP, это не обязательно взлом, но типичный шум ботов. Если же после отключения у вас перестали работать публикации из внешнего клиента, значит XML-RPC был нужен.
Ещё один практичный признак: если в панели безопасности WordPress вы видите много неудачных попыток авторизации, а все они идут через xmlrpc.php, закрытие доступа имеет смысл. Но сначала убедитесь, что это не ваш легитимный сервис.
Как закрыть xmlrpc.php: сравнение подходов
| Способ | Что делает | Когда подходит | Минус |
|---|---|---|---|
| Через сервер | Блокирует запросы до WordPress | Если нужен жёсткий запрет | Нужно иметь доступ к конфигу nginx/apache |
| Через PHP/WordPress | Отдаёт ошибку на уровне CMS | Если нельзя трогать сервер | Запрос всё равно доходит до WordPress |
| Плагин безопасности | Даёт переключатель в админке | Если нужен быстрый вариант без кода | Зависимость от плагина |
Пошаговое решение
Вариант 1: блокировка на уровне сервера
Это самый надёжный способ, потому что запросы к xmlrpc.php не доходят до WordPress. Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для nginx логика похожая, но правило добавляется в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После правки конфигурации проверьте синтаксис и перезагрузите веб-сервер. На shared-хостинге это не всегда доступно, поэтому иногда проще использовать следующий вариант.
Вариант 2: отключение через WordPress-код
Если серверный доступ ограничен, можно заблокировать XML-RPC на уровне WordPress. Добавьте код в functions.php дочерней темы или в небольшой mu-plugin:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот способ простой, но не самый жёсткий. Запрос всё равно попадёт в WordPress, просто CMS ответит, что XML-RPC отключён. Для большинства сайтов этого достаточно.
Вариант 3: отключение только pingback’ов
Иногда XML-RPC нужен, но pingback’и нет. Тогда лучше не рубить всё целиком, а отключить только этот механизм. Это полезно, если вы хотите сохранить совместимость с внешними клиентами, но убрать лишний шум и часть злоупотреблений.
<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['pingback.extensions.getPingbacks'] );
return $methods;
} );Такой вариант не решает все риски, но уменьшает поверхность атаки и убирает одну из самых бесполезных функций для большинства современных сайтов.
Проверка результата после внедрения
После изменения откройте /xmlrpc.php в браузере или проверьте ответ через curl. В зависимости от способа блокировки вы должны увидеть отказ в доступе, сообщение об отключении или пустой ответ от сервера.
curl -I https://example.com/xmlrpc.phpЕсли блокировка сделана на уровне nginx или Apache, в ответе обычно будет 403 Forbidden. Если отключение выполнено через WordPress-фильтр, возможен ответ с текстом о том, что XML-RPC отключён.
Дополнительно проверьте:
- работает ли вход в админку обычным способом;
- не сломалась ли публикация из Jetpack или мобильного приложения;
- не появились ли ошибки в логах сервера;
- не выросло ли число 404/403 на других URL после правок конфигурации.
Частые ошибки и как их исправить
Сломали Jetpack или внешний клиент
Это самая частая проблема. Если после отключения перестали работать синхронизация, публикация или статистика, значит сервис использовал XML-RPC. Решение простое: либо вернуть доступ, либо перевести интеграцию на другой способ, если он поддерживается.
Добавили правило не туда
Для Apache правило в .htaccess работает только если модуль доступа разрешает такие директивы. Для nginx этот файл вообще не используется. Если после правки ничего не изменилось, проверьте, какой веб-сервер реально обслуживает сайт.
Отключили XML-RPC плагином, но запросы всё равно видны
Плагин может блокировать функциональность внутри WordPress, но не всегда отсекает сам HTTP-запрос. Если цель — снизить нагрузку и убрать шум в логах, лучше закрывать доступ на уровне сервера.
Забыли про кэш и проверяют старый ответ
Если перед сайтом стоит CDN или reverse proxy, старый ответ может сохраняться. После изменений очистите кэш на сервере, в CDN и в плагине кэширования, если он есть.
Что делать, если XML-RPC нужен частично
Иногда удобнее не отключать файл полностью, а ограничить только опасные методы. Это компромиссный вариант для сайтов, где есть зависимость от внешнего клиента, но pingback’и и лишние методы не нужны.
В таких случаях лучше начать с анализа: какие сервисы реально обращаются к xmlrpc.php, какие методы они используют и можно ли заменить их REST API или прямой интеграцией через плагин. Если сервис современный, почти всегда есть более безопасная альтернатива XML-RPC.
Практические советы по безопасности и производительности
- Не отключайте XML-RPC вслепую на клиентских проектах, где есть мобильное приложение или Jetpack.
- Если нужен жёсткий запрет, делайте его на уровне сервера, а не только через WordPress.
- После изменений проверяйте логи хотя бы несколько дней: иногда проблема проявляется не сразу.
- Если на сайте много брутфорса, закрытие
xmlrpc.phpстоит сочетать с ограничением попыток входа и нормальной политикой паролей. - Не ставьте несколько плагинов, которые делают одно и то же: можно получить конфликт фильтров и ложные срабатывания.
Если вам нужен более широкий набор мер по чистке сайта и отключению лишних функций, иногда удобнее использовать один инструмент вместо набора разрозненных плагинов. Например, в Clearfy Pro есть блоки для отключения ненужных возможностей WordPress и снижения технического шума: https://wpshop.ru/plugins/clearfy.
Как понять, что решение сработало
Результат считается нормальным, если выполняются три условия: xmlrpc.php больше не отвечает как раньше, легитимные сервисы не сломались, а в логах исчезли массовые обращения к этому файлу или они стали получать отказ до WordPress.
Если после блокировки сайт работает штатно, а в панели хостинга меньше мусорных запросов, значит вы выбрали правильный уровень ограничения. Если же что-то перестало публиковаться или синхронизироваться, откатите изменение и проверьте зависимости по списку выше.