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

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

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

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

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

Отключать можно, если

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

Не отключайте сразу, если

• Jetpack у вас реально используется и часть функций завязана на связь с WordPress.com;
• есть интеграции со сторонними системами, которые вы не проверяли после отключения;
• вы не уверены, чем именно пользуется редакция или подрядчики.

Диагностика: кто вообще ходит в xmlrpc.php

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

Если у вас есть доступ к access.log, ищите запросы к /xmlrpc.php. В nginx это можно сделать так:

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

Если видите только частые POST-запросы с одинаковых или подозрительных адресов, это типичный кандидат на блокировку. Если среди обращений есть ваши сервисы, сначала проверьте их настройки.

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

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

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

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

Самый простой способ — запретить использование XML-RPC фильтром xmlrpc_enabled. Это стандартный хук WordPress, он не выдуман и работает предсказуемо.

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

Код можно добавить в functions.php дочерней темы, но для боевого сайта надёжнее вынести его в mu-plugin, чтобы он не зависел от смены темы. Пример минимального mu-plugin:

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

Если нужен более жёсткий вариант, можно дополнительно вернуть 403 на сам файл на уровне WordPress. Но обычно фильтра достаточно, если задача — отключить функциональность, а не блокировать доступ на уровне веб-сервера.

Вариант 2. Блокировка на сервере

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

Для nginx можно использовать отдельное правило:

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

Для Apache обычно используют правило в .htaccess:

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

Серверная блокировка хороша тем, что не нагружает PHP. Но если у вас несколько сайтов на одном сервере и разные требования к XML-RPC, следите, чтобы правило не попало в общий шаблон без проверки.

Вариант 3. Плагин безопасности

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

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

Пошаговое решение для типового сайта

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

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

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

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

Дальше проверьте реальные интеграции:

• если используется Jetpack — убедитесь, что он подключается и не теряет связь;
• если есть мобильное приложение WordPress — попробуйте авторизацию и черновик;
• если есть внешняя публикация — выполните тестовый пост в staging или на тестовом аккаунте;
• посмотрите access.log: запросы к xmlrpc.php должны либо исчезнуть, либо получать отказ.

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

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

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

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

Поставили сразу и код, и правило в nginx, и плагин

Так делать не нужно. Когда всё заблокировано несколькими слоями, потом трудно понять, что именно мешает работе. Оставьте один основной способ и задокументируйте его в проекте.

Добавили правило в .htaccess, но сайт на nginx

Это частая ошибка при переносе хостинга. Для nginx .htaccess не работает вообще. Проверяйте, какой веб-сервер реально обслуживает сайт, и вносите правки туда, где они поддерживаются.

Отключили XML-RPC, но боты продолжают стучаться

Это нормально: попытки будут идти, пока файл доступен по URL. Серверная блокировка обычно эффективнее, потому что отсекает запрос раньше. Если нагрузка заметная, лучше закрывать файл на уровне nginx или Apache.

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

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

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

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

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