Как отключить XML-RPC в WordPress без поломки плагинов и мобильных приложений

XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно ломают удалённую публикацию, Jetpack, мобильное приложение или интеграцию с внешним сервисом. Проблема не в самом факте отключения, а в том, что его делают без диагностики: сначала режут доступ, потом ищут, что именно перестало работать.

Если задача — убрать лишнюю поверхность атаки и при этом не сломать рабочие сценарии, лучше идти от проверки фактического использования XML-RPC. Ниже — рабочая схема: как понять, нужен ли он вообще, как отключить его точечно и как убедиться, что ничего важного не отвалилось.

Когда XML-RPC действительно стоит отключать

XML-RPC нужен не всем. На большинстве сайтов его используют редко: либо старые интеграции, либо отдельные приложения, либо сервисы, которые давно можно заменить REST API. Если сайт не публикует контент удалённо, не синхронизируется со сторонними клиентами и не использует плагины, завязанные на XML-RPC, отключение обычно оправдано.

Но есть нюанс: некоторые плагины и сервисы не всегда явно показывают зависимость. Поэтому перед изменениями полезно проверить, обращается ли кто-то к /xmlrpc.php вообще.

Быстрая диагностика проблемы

Сначала смотрим логи веб-сервера или WAF, если они есть. Ищем запросы к /xmlrpc.php. Если видите только массовые брутфорс-запросы, а легитимных обращений нет — это хороший кандидат на отключение.

Если доступ к логам ограничен, можно временно проверить ответ напрямую:

curl -I https://example.com/xmlrpc.php

Нормальный ответ сам по себе не доказывает использование, но показывает, что файл доступен извне. Для диагностики важнее понять, кто и зачем его вызывает. Если у вас установлен Jetpack, мобильное приложение WordPress или старый клиент для публикации, сначала проверьте их настройки.

Как отключить XML-RPC безопасно

Есть несколько способов. Самый надёжный — на уровне сервера или через код, если нужен контроль в репозитории. Плагины тоже подходят, но только если вы понимаете, что именно они делают и не конфликтуют с другими правилами безопасности.

Вариант через код

Если нужен предсказуемый результат, добавьте код в mu-plugin или в собственный плагин. Так решение не потеряется при смене темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

Этот вариант отключает XML-RPC на уровне WordPress. Для большинства сайтов этого достаточно.

Вариант через сервер

Если хотите отрезать запросы раньше, можно закрыть xmlrpc.php на уровне nginx. Это полезно, когда идёт мусорный трафик и вы не хотите даже запускать WordPress на такие запросы.

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Для Apache логика будет другой, но смысл тот же: запретить прямой доступ к файлу. Если у вас нет уверенности в конфиге сервера, не вносите изменения вслепую — сначала проверьте, как устроен текущий виртуальный хост.

Что проверить после отключения

После внедрения важно не просто убедиться, что /xmlrpc.php перестал отвечать, а проверить реальные сценарии сайта. Иначе можно получить «безопасность» ценой сломанной публикации.

Проверка результата

• Откройте https://example.com/xmlrpc.php в браузере или через curl: доступ должен быть закрыт или возвращать ожидаемый отказ.
• Попробуйте авторизацию в Jetpack, если он используется.
• Проверьте мобильное приложение WordPress, если редакторы публикуют через него.
• Посмотрите логи сайта на предмет ошибок 403, 404 или всплеска неудачных запросов.
• Убедитесь, что REST API и обычная админка работают как раньше.

Если после отключения что-то перестало синхронизироваться, не возвращайте XML-RPC «на всякий случай». Сначала найдите конкретную интеграцию, которая его требует. Иногда достаточно перевести сервис на REST API или обновить настройки подключения.

Частые ошибки и как их исправить

Отключили XML-RPC, но забыли про Jetpack

Jetpack в некоторых сценариях использует XML-RPC для связи с сайтом. Если после отключения перестала работать статистика, публикация или удалённые функции, проверьте, действительно ли этот модуль нужен. Иногда достаточно переподключить сервис после изменения настроек, но иногда проще оставить XML-RPC включённым и закрыть его дополнительными мерами защиты.

Поставили плагин безопасности и получили конфликт

Некоторые плагины безопасности уже умеют блокировать XML-RPC. Если вы добавляете ещё и ручное правило в .htaccess или nginx, можно получить двойную блокировку и путаницу при отладке. В такой ситуации оставьте один источник истины: либо сервер, либо плагин, либо код.

Сломали удалённую публикацию у редакторов

Это типичный случай, когда отключение делали без списка зависимостей. Перед изменениями нужно собрать все каналы публикации: мобильные приложения, внешние CMS, сервисы автопостинга, старые интеграции. Если хотя бы один из них использует XML-RPC, отключение нужно согласовать с владельцами процесса.

Проверили только главную страницу и успокоились

Главная страница может работать идеально, а проблема проявится только в API-интеграции или в приложении редактора. Проверяйте именно тот сценарий, ради которого сайт живёт, а не только видимую часть фронтенда.

Практические меры безопасности и производительности

Отключение XML-RPC — не замена нормальной защите входа. Если у вас слабые пароли, нет ограничений на попытки входа и не обновляются плагины, одна только блокировка xmlrpc.php не спасёт.

Что имеет смысл сделать вместе с этим:

• включить двухфакторную аутентификацию для админов;
• ограничить число попыток входа;
• проверить, не торчит ли wp-login.php без защиты;
• обновить ядро, темы и плагины;
• убрать неиспользуемые интеграции и старые учётные записи;
• посмотреть, не создаёт ли XML-RPC лишнюю нагрузку в логах и на уровне WAF.

Если на сайте много технического мусора — дубли, лишние мета-теги, неиспользуемые скрипты и старые интеграции — имеет смысл пройтись по общей чистке. В таких задачах часто помогает Clearfy Pro: он закрывает часть типовых проблем с дублями и технической оптимизацией, но использовать его нужно как инструмент, а не как замену ревизии сайта.

Когда XML-RPC лучше не отключать

Есть сценарии, где отключение принесёт больше вреда, чем пользы. Например, если редакция публикует через мобильное приложение, а альтернативы нет; если сайт связан со старым внешним сервисом, который нельзя быстро перевести на REST API; если интеграция поддерживается подрядчиком и вы не контролируете её код.

В таких случаях разумнее не рубить доступ полностью, а ограничить его другими мерами: закрыть брутфорс, поставить rate limiting, следить за логами и оставить XML-RPC только до миграции на более современный способ интеграции.

Итоговая проверка здесь простая: если после отключения не осталось ни одного реального клиента, который обращается к /xmlrpc.php, значит решение сработало. Если хотя бы один рабочий сценарий сломался, откатите изменение и разберите зависимость до повторной попытки.