XML-RPC в WordPress часто отключают «на всякий случай», а потом ловят неожиданные побочные эффекты: перестаёт работать публикация через сторонние клиенты, ломаются старые интеграции, а иногда и защита от брутфорса настроена не там, где нужно. Если задача именно в том, чтобы убрать лишний входной канал и снизить поверхность атаки, делать это лучше осознанно: сначала понять, кто вообще ходит в /xmlrpc.php, затем выбрать способ отключения и только потом проверять результат.
Когда XML-RPC действительно стоит отключать
В современных установках WordPress XML-RPC нужен не всем. Если сайт не использует мобильные приложения WordPress, внешние редакторы, Jetpack в старом режиме, системные интеграции через XML-RPC или удалённую публикацию, этот endpoint обычно только создаёт лишний риск. На практике его чаще оставляют включённым по инерции, а не потому, что он реально нужен.
Но отключение не должно быть «по шаблону». Если у вас есть:
- старый клиент для публикации записей;
- интеграция с сервисом, который работает через XML-RPC, а не REST API;
- мобильное приложение WordPress, которое всё ещё использует этот канал в вашем сценарии;
- плагин, завязанный на
xmlrpc.phpдля удалённых операций;
— сначала проверьте зависимость, иначе получите неочевидную поломку, которую потом сложно связать с изменением.
Диагностика: кто обращается к xmlrpc.php
Самый полезный шаг — не отключать endpoint вслепую, а посмотреть, есть ли к нему реальные запросы. Если у вас есть доступ к логам веб-сервера, найдите обращения к /xmlrpc.php за последние дни. Это сразу покажет, идёт ли трафик от ботов, сканеров или от легитимных клиентов.
Что искать в логах
В access-логах nginx или Apache обычно достаточно фильтра по строке xmlrpc.php. Если запросы идут пачками с одинаковых IP и с ошибками 401/403/404, это почти всегда автоматический перебор. Если же видны редкие успешные POST-запросы, стоит проверить источник внимательнее.
grep