Как отключить XML-RPC в WordPress и проверить, что сайт действительно защищён

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

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

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

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

Типичные признаки, что endpoint лучше закрыть

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

Диагностика: как понять, открыт ли XML-RPC сейчас

Проверка простая: запросите https://ваш-домен/xmlrpc.php. Если endpoint доступен, WordPress обычно отвечает не страницей сайта, а служебным сообщением. Это ещё не значит, что сайт взломан, но значит, что точка входа активна.

Дополнительно полезно посмотреть access log веб-сервера. Если там много обращений к xmlrpc.php с разных IP, это хороший аргумент для отключения или хотя бы ограничения доступа на уровне сервера.

Что проверить до изменений

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

Как отключить XML-RPC в WordPress

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

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

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

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

add_filter( 'xmlrpc_enabled', '__return_false' );

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

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

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

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

Для старых конфигураций Apache иногда встречается синтаксис с Deny from all, но на современных серверах лучше использовать Require all denied.

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

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

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

После отключения не ограничивайтесь «вроде всё работает». Проверьте endpoint напрямую и убедитесь, что он больше не отвечает как раньше.

Проверка через браузер или curl

Откройте /xmlrpc.php в браузере. Если доступ закрыт через сервер, вы увидите 403 или 404 в зависимости от конфигурации. Если отключение сделано через WordPress-фильтр, ответ может отличаться, но endpoint не должен принимать рабочие XML-RPC-запросы.

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

Если сервер возвращает 403 Forbidden, это хороший признак. Если ответ 200 OK, значит, файл по-прежнему доступен, и нужно смотреть, где именно сработала блокировка.

Проверка функциональности сайта

После изменения обязательно проверьте:

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

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

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

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

Поставили правило в .htaccess, но файл всё ещё открывается

Частая причина — сайт работает не на Apache, а на Nginx, либо правило добавлено не в тот блок конфигурации. В таком случае .htaccess не поможет. Нужно настраивать серверный конфиг или использовать фильтр WordPress.

Использовали плагин, но забыли проверить кэш

Иногда старый кэш страницы или прокси может создавать впечатление, что endpoint ещё доступен. Для проверки используйте прямой запрос к /xmlrpc.php, а не только просмотр кэшированной страницы сайта.

Сломали интеграцию, но не знаете какую

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

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

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

Если у вас несколько сайтов на одном сервере, полезно закрывать endpoint на уровне веб-сервера, а не только внутри WordPress. Так вы уменьшаете лишние обращения и экономите ресурсы на обработке запросов.

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

Короткий чек-лист перед публикацией изменений

• Проверили, нужен ли XML-RPC конкретным сервисам.
• Выбрали способ отключения: код, сервер или плагин.
• Сделали резервную копию файла конфигурации или mu-plugin.
• Проверили ответ /xmlrpc.php после изменения.
• Убедились, что Jetpack и другие интеграции не сломались.
• Посмотрели логи на предмет повторных обращений.

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