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

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

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

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

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

Сценарии, где отключение обычно оправдано:

• сайт не подключён к Jetpack или Jetpack не использует XML-RPC для нужных функций;
• нет публикации через сторонние клиенты и десктопные приложения;
• в логах заметны массовые запросы к /xmlrpc.php;
• нужно сократить лишние точки входа для брутфорса.

Что может зависеть от XML-RPC

Самые частые зависимости — это Jetpack, старые приложения WordPress для iOS/Android, внешние сервисы автопостинга и некоторые интеграции с CRM или планировщиками публикаций. Если вы не уверены, сначала проверьте, кто именно обращается к сайту, а не отключайте файл вслепую.

Диагностика: как понять, используется ли xmlrpc.php

Начните с логов веб-сервера. Если у вас есть доступ к access log, ищите обращения к /xmlrpc.php. Важно смотреть не только на факт запросов, но и на их источник: если это один и тот же IP или набор подозрительных адресов, речь может идти о сканировании, а не о реальном использовании.

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

Если у вас Apache, путь к логам может отличаться, но принцип тот же. Дополнительно можно проверить, не использует ли сайт Jetpack или другие сервисы, завязанные на удалённое подключение. В админке это обычно видно по активным плагинам и их настройкам.

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

Как отключить XML-RPC: три рабочих варианта

Выбор зависит от того, где вам удобнее управлять доступом: на уровне плагина, темы или веб-сервера. Самый предсказуемый вариант — блокировка на уровне сервера, но если нужен быстрый и обратимый способ, можно использовать код.

Вариант 1: отключить через код

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

add_filter( 'xmlrpc_enabled', '__return_false' );

Этот фильтр отключает XML-RPC на уровне WordPress. Запросы к xmlrpc.php могут по-прежнему доходить до сервера, но сам WordPress не будет обрабатывать XML-RPC как рабочий интерфейс.

Вариант 2: закрыть файл на уровне nginx

Если сайт работает на nginx, можно отдать 403 до передачи запроса в PHP. Это снижает лишнюю нагрузку и убирает обработку запроса WordPress-ом.

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

После изменения конфигурации не забудьте проверить синтаксис и перезагрузить nginx. На боевом сервере это лучше делать только после теста на staging.

Вариант 3: ограничить через Apache

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

<Files xmlrpc.php>
    Require all denied
</Files>

Если сайт работает через старую конфигурацию Apache, синтаксис может отличаться. В современных установках Require all denied — нормальный вариант.

Пошаговое решение без сюрпризов

1. Проверьте, используется ли XML-RPC в текущих интеграциях и плагинах.
2. Сделайте резервную копию или подготовьте откат конфигурации.
3. Выберите один способ блокировки: код, nginx или Apache.
4. Внесите изменение сначала на тестовой копии сайта.
5. Проверьте доступ к /xmlrpc.php и работу внешних сервисов.
6. Если всё чисто, перенесите изменение на боевой сайт.

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

Как проверить, что отключение сработало

Самый простой тест — открыть https://ваш-домен/xmlrpc.php в браузере. В зависимости от способа блокировки вы увидите либо 403, либо сообщение WordPress о том, что XML-RPC сервер принимает только POST-запросы. Если вы отключали фильтром xmlrpc_enabled, важно проверить именно поведение при POST-запросе, а не только страницу в браузере.

Для более точной проверки можно отправить тестовый запрос через curl:

curl -i -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Если доступ закрыт корректно, вы не должны получать рабочий ответ XML-RPC. При блокировке на сервере обычно будет 403. При отключении через WordPress ответ может зависеть от того, как именно запрос дошёл до PHP.

После этого проверьте:

• Jetpack, если он установлен;
• публикацию из внешних сервисов;
• мобильные приложения WordPress, если ими пользуются;
• логи сервера на предмет новых ошибок.

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

Отключили XML-RPC, а потом перестал работать Jetpack

Это типичная ситуация, если Jetpack использовался для функций, завязанных на удалённое соединение. Решение простое: либо вернуть XML-RPC, либо перевести нужный сценарий на другой способ интеграции, если он поддерживается конкретной функцией плагина.

Закрыли файл на сервере, но запросы всё равно идут

Иногда блокировка настроена только на уровне WordPress, а в логах всё равно видно обращения к xmlrpc.php. Это нормально: запросы могут доходить до веб-сервера, но не обрабатываться WordPress. Если цель — снизить нагрузку и шум в логах, блокируйте на уровне nginx или Apache.

Сломали доступ из-за неверного правила

Ошибка в конфиге nginx или .htaccess может повлиять не только на XML-RPC. Поэтому правило нужно проверять отдельно и не смешивать его с другими изменениями. Если после правки сайт начал отдавать 500, первым делом откатите последнее правило и проверьте синтаксис конфигурации.

Отключили через плагин, но забыли про кэш

Если на сайте есть серверный кэш, CDN или плагин кэширования, старый ответ может какое-то время сохраняться. После изменения очистите кэш на всех уровнях, иначе проверка даст ложный результат.

Безопасность и производительность: что ещё стоит сделать рядом

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

Полезный минимум:

• ограничить попытки входа в админку;
• включить двухфакторную аутентификацию для администраторов;
• убрать неиспользуемые плагины и темы;
• следить за логами 404 и 403, чтобы видеть сканирование;
• не держать активными старые интеграции, которые уже не используются.

Если вам нужен более широкий набор инструментов для чистки сайта и отключения лишних функций, уместно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже в этом случае не стоит включать всё подряд — сначала проверьте, что именно вам мешает, а что реально используется.

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

Если сайт активно использует внешнюю публикацию, старые мобильные клиенты или специализированные сервисы, которые вы не готовы перенастраивать, полное отключение может создать больше проблем, чем пользы. В таком случае лучше ограничить доступ на уровне firewall, rate limit или настроить защиту от брутфорса, а не рубить функциональность целиком.

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