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

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

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

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

Но сначала проверьте зависимости. XML-RPC может понадобиться, если:

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

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

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

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

Если у вас есть SSH-доступ, можно быстро посмотреть, кто стучится чаще всего:

grep "xmlrpc.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head

Эта команда не решает проблему сама по себе, но помогает понять, есть ли смысл отключать XML-RPC полностью или сначала ограничить доступ на уровне WAF, fail2ban или nginx.

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

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

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

Если вам нужен предсказуемый способ без плагинов, добавьте фильтр xmlrpc_enabled в functions.php дочерней темы или, лучше, в MU-плагин. Для постоянной технической настройки MU-плагин безопаснее: он не зависит от темы и не исчезнет при смене шаблона.

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

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

Вариант 2: закрыть доступ на уровне nginx

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

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

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

Вариант 3: использовать плагин безопасности

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

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

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

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

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

После внедрения не ограничивайтесь открытием страницы в браузере. Нужна проверка именно ответа сервера. Самый простой вариант — curl:

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

Если вы закрывали endpoint на уровне nginx или через код, в ответе должен быть 403 или другой отказ, а не стандартный ответ WordPress. Для более точной проверки можно отправить POST-запрос:

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

Если endpoint закрыт корректно, вы не должны получить список методов WordPress. Дополнительно проверьте:

• нет ли новых ошибок в error_log;
• не сломались ли внешние публикации, если они были;
• не начал ли плагин безопасности блокировать лишнее на уровне WAF;
• не остался ли старый кеш с доступной страницей ответа.

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

Отключили XML-RPC, но endpoint всё ещё отвечает

Частая причина — правило добавили не туда. Например, код лежит в активной теме, а сайт уже переключён на другую; или правило в nginx не применилось из-за неверного reload конфигурации. Проверьте место размещения кода и перезапуск/перечитку конфигурации сервера.

Сломался Jetpack или мобильное приложение

Значит, XML-RPC был нужен. В такой ситуации не стоит «ломать через колено» — верните доступ и переведите интеграцию на актуальный способ подключения, если он доступен. Для некоторых сценариев лучше ограничить доступ по IP или через WAF, чем закрывать endpoint полностью.

Плагин безопасности показывает, что всё отключено, но запросы проходят

Некоторые плагины меняют поведение только на уровне WordPress, а не веб-сервера. Это значит, что запрос всё равно доходит до PHP. Если нужна реальная экономия ресурсов и более жёсткая блокировка, закрывайте файл на уровне nginx/apache.

После отключения выросло число 404 или 403 в логах

Это нормально, если боты продолжают стучаться в старый endpoint. Важно не количество самих попыток, а то, что они больше не доходят до логики WordPress. Если шум слишком большой, добавьте правило в WAF или fail2ban, но не превращайте это в набор взаимоисключающих блокировок.

Что делать для безопасности и производительности дополнительно

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

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

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

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

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

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