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