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