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