Файл xmlrpc.php часто отключают «на всякий случай», а потом удивляются, что перестала работать публикация из старых мобильных клиентов, внешние сервисы или часть интеграций. Проблема не в самом XML-RPC как концепции, а в том, что на живом сайте его лучше отключать только после проверки, кто и зачем к нему обращается.
Если у вас уже есть статьи про REST API и sitemap, следующий практический шаг — разобраться именно с xmlrpc.php: как увидеть обращения, когда его можно закрыть полностью, а когда лучше ограничить точечно.
Когда xmlrpc.php действительно нужно отключать
Чаще всего этот файл оставляют открытым по привычке. На современных сайтах он нужен редко, но есть исключения. Перед изменениями проверьте, используете ли вы:
- старые мобильные приложения WordPress для публикации;
- Jetpack в режимах, где он опирается на XML-RPC;
- внешние сервисы автопостинга, которые не умеют работать через REST API;
- интеграции с редакторами или CMS, которые отправляют записи по XML-RPC.
Если ничего из этого нет, отключение обычно безопасно. Но сначала полезно убедиться, что запросы к файлу вообще есть.
Диагностика: кто обращается к xmlrpc.php
Самая частая ошибка — закрыть доступ до проверки логов. В результате ломают не атаку, а рабочий сценарий. Начните с access-логов веб-сервера или логов CDN/WAF, если они у вас есть.
Что искать в логах
Ищите запросы к /xmlrpc.php, особенно если они идут пачками с одного IP или с типичными методами вроде system.multicall. Это не всегда атака, но такой паттерн стоит проверить.
grep