Как отключить XML-RPC в WordPress-блоге и не сломать нужные интеграции

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

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

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

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

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

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

Диагностика: нужен ли XML-RPC именно вашему блогу

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

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

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

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

Как отключить XML-RPC в WordPress-блоге: рабочие варианты

Есть три практических подхода: через код, через плагин и на уровне сервера. Для блога обычно достаточно кода или плагина. Серверный уровень имеет смысл, если вы хотите отрезать запросы ещё до загрузки WordPress.

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

Если вы ведёте блог и можете добавить код в дочернюю тему или в mu-plugin, используйте фильтр xmlrpc_enabled. Это самый понятный способ: WordPress продолжит работать, но XML-RPC будет отключён.

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

Лучше не класть такой код в основную тему, если вы часто её обновляете. Для блога надёжнее использовать mu-plugin: тогда код не потеряется при смене темы.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Файл можно положить в wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную.

Вариант 2: отключение через плагин

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

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

Вариант 3: блокировка на уровне сервера

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

Для Apache это обычно делается через .htaccess:

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

Для Nginx правило зависит от конфигурации сайта, но логика та же: вернуть 403 на запрос к /xmlrpc.php. Если вы не уверены в конфиге, не правьте его на боевом сайте без бэкапа и доступа к откату.

Пошаговое решение для блога

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

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

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

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

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

• публикацию новой записи из админки;
• редактирование существующей записи;
• работу подключённых плагинов, которые могут отправлять данные наружу;
• отсутствие ошибок в журнале сервера и в wp-content/debug.log, если у вас включён WP_DEBUG_LOG.

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

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

Отключили XML-RPC и сломали Jetpack

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

Удалили файл xmlrpc.php вручную

Так делать не стоит. При обновлении WordPress файл может восстановиться, а ещё вы усложняете диагностику. Лучше блокировать доступ, а не ломать структуру ядра.

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

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

Заблокировали XML-RPC, но не закрыли другие точки входа

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

Что ещё стоит сделать для безопасности блога

Отключение XML-RPC — это только один слой. Для блога полезно дополнительно:

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

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

Чек-лист перед отключением XML-RPC

• Проверены внешние редакторы и мобильные приложения.
• Понятно, какие плагины используют удалённую публикацию.
• Есть резервная копия.
• Выбран способ отката.
• Проверена публикация записи после изменения.
• Проверен ответ /xmlrpc.php и логи сервера.

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