Как отключить XML-RPC в WordPress и не сломать Jetpack и мобильное приложение

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

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

Когда XML-RPC можно отключать без риска

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

Сценарии, где XML-RPC чаще всего не нужен

редакторы заходят только в /wp-admin/;
нет Jetpack или он не использует удалённую синхронизацию;
не используется приложение WordPress для iOS/Android;
нет внешних клиентов для публикации по XML-RPC;
не подключены старые сервисы автопостинга, которые работают только через XML-RPC.

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

Диагностика: как понять, кто обращается к xmlrpc.php

Самый простой способ — посмотреть логи веб-сервера. Если у вас есть доступ к access log, найдите запросы к /xmlrpc.php и оцените частоту, IP и user-agent. Это сразу покажет, идёт ли туда реальный трафик или это только сканирование ботами.

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

Если логов нет под рукой, можно временно включить аудит на уровне сервера или использовать плагин безопасности, который показывает обращения к файлам ядра. Но для принятия решения достаточно даже короткой выборки: если видите только массовые POST-запросы с одинаковых IP, это не аргумент против отключения. Если же в логах есть запросы от Jetpack или мобильного клиента, блокировать нужно аккуратно.

Что проверить перед отключением

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

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

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

Способ	Плюсы	Минусы
Код в теме или mu-plugin	Просто, прозрачно, без лишних зависимостей	Нужно не забыть о совместимости с Jetpack
Правило на сервере	Режет запросы раньше WordPress	Зависит от Nginx/Apache и доступа к конфигу
Плагин безопасности	Быстро включить без кода	Лишняя нагрузка и риск дублирования функций

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

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

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

Такой вариант отключает XML-RPC на уровне WordPress. Если кто-то обратится к xmlrpc.php, WordPress не будет обрабатывать запрос как рабочий API.

Вариант 2: заблокировать доступ на уровне Nginx

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

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

Для Apache логика будет другой, но смысл тот же: запретить прямой доступ к файлу. Этот способ не стоит применять, если вы не проверили интеграции, потому что WordPress уже не сможет принять XML-RPC-запросы вообще.

Вариант 3: оставить файл, но ограничить доступ

Иногда XML-RPC нужен только для конкретного сервиса. Тогда вместо полного запрета лучше ограничить доступ по IP или закрыть его на уровне WAF/Firewall. Это уже более точечная настройка, но она требует дисциплины: если IP изменится, интеграция сломается.

Что делать, если нужен Jetpack или мобильное приложение

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

Для мобильного приложения WordPress ситуация похожая: если редакторы реально публикуют материалы с телефона, отключение XML-RPC может сделать этот сценарий невозможным. Тогда лучше не ломать всё целиком, а оставить доступ и закрыть его дополнительными мерами: сильные пароли, 2FA, ограничение логинов, защита от перебора и актуальные обновления.

Пошаговое решение без лишнего риска

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

Для сайтов с нормальным процессом деплоя лучше оформить это как отдельный технический change: так проще откатить изменение, если кто-то из редакторов внезапно обнаружит, что его привычный сценарий публикации больше не работает.

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

Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере и посмотрите, что происходит. Если доступ закрыт на сервере, вы увидите отказ в доступе или 403. Если отключение сделано через фильтр WordPress, поведение может отличаться, но запрос не должен выполнять полезную работу.

Дополнительно проверьте:

Jetpack не потерял связь с сайтом;
мобильное приложение WordPress может или не может публиковать записи — в зависимости от вашего решения;
в логах больше не появляются успешные POST-запросы к xmlrpc.php;
сайт не начал выдавать ошибки в админке после изменения.

Если вы блокировали доступ на Nginx, полезно ещё раз посмотреть access log: там не должно быть 200-ответов на /xmlrpc.php. Повторяющиеся 403 — это нормально, если бот продолжает стучаться. Это уже вопрос фильтрации шума, а не функциональности сайта.

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

Отключили XML-RPC, не проверив Jetpack

Это самая частая проблема. Пользователь видит, что статистика, публикация или синхронизация перестали работать, и не связывает это с недавним изменением. Исправление простое: либо вернуть доступ, либо перевести нужную функцию на другой механизм.

Заблокировали файл на сервере, но оставили старый плагин безопасности

Иногда несколько решений делают одно и то же. В результате вы получаете дублирующиеся правила, сложный дебаг и ложные срабатывания. Лучше оставить один понятный способ блокировки и документировать его в проекте.

Использовали плагин, который отключает слишком много

Некоторые плагины безопасности не только закрывают XML-RPC, но и меняют поведение REST API, авторизацию или доступ к системным файлам. Если после установки появились побочные эффекты, проверьте, что именно делает плагин, и не полагайтесь на «одну кнопку для всего».

Сделали запрет без тестовой копии

На живом сайте это особенно неприятно, если редакция работает по расписанию. Минимум — проверьте изменение на staging. Если staging нет, хотя бы сохраните способ быстрого отката: кусок кода, правило сервера и список зависимых сервисов.

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

Отключение XML-RPC само по себе не делает сайт «защищённым», но убирает один из популярных векторов шумной активности. Это полезно в связке с другими базовыми мерами: ограничением попыток входа, 2FA для админов, актуальными версиями WordPress и плагинов, нормальными паролями и отключением ненужных сервисов.

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

Если нужен более широкий технический аудит сайта — от дублей и индексации до чистки лишних функций — имеет смысл смотреть на комплексные инструменты вроде Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpdream.ru&utm_medium=article&utm_campaign=kak-otklyuchit-xml-rpc-v-wordpress-i-ne-slomat-jetpack-i-mobilnoe-prilozhenie. Но даже в этом случае не стоит включать всё подряд: сначала проверяйте, что именно меняется в конкретном проекте.

Мини-чек-лист перед отключением

Проверены логи на обращения к xmlrpc.php.
Понятно, используется ли Jetpack.
Проверено мобильное приложение WordPress.
Есть тестовая копия или понятный план отката.
Выбран один способ блокировки, без дублирования правил.
После изменения проверен ответ /xmlrpc.php и рабочие интеграции.

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