XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация или старые интеграции. На практике задача не в том, чтобы просто заблокировать файл xmlrpc.php, а в том, чтобы понять, нужен ли он вообще вашему сайту, и если нет — закрыть его без побочных эффектов.
Ниже — рабочая схема: как диагностировать использование XML-RPC, чем его отключать, как проверить результат и где чаще всего ошибаются.
Когда XML-RPC действительно стоит отключать
Если сайт не использует внешние клиенты для публикации, Jetpack-функции, старые мобильные приложения WordPress или интеграции, завязанные именно на XML-RPC, этот интерфейс обычно только расширяет поверхность атаки. Чаще всего его отключают на обычных корпоративных сайтах, блогах и лендингах, где весь контент редактируется только через админку.
Но есть важная оговорка: если у вас уже подключён сервис, который синхронизирует записи через XML-RPC, простая блокировка приведёт к ошибкам авторизации и публикации. Поэтому сначала нужна проверка, а не сразу запрет.
Диагностика: используется ли xmlrpc.php сейчас
Самый простой способ — посмотреть логи веб-сервера и обращения к /xmlrpc.php. Если там есть регулярные запросы от ваших сервисов, отключать интерфейс без замены нельзя.
Проверка по логам
На сервере с Nginx можно быстро найти обращения так:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20Для Apache принцип тот же, только путь к логам будет другим. Если запросы идут с неизвестных IP и выглядят как массовый перебор, это уже аргумент в пользу отключения.
Проверка через сам WordPress
Если у вас есть доступ к коду, можно временно добавить простой тест в плагин или functions.php, чтобы понять, не вызывается ли XML-RPC изнутри сайта или сторонними плагинами. Но на практике логов обычно достаточно.
Как отключить XML-RPC безопасно
Есть три нормальных варианта: через код, через сервер и через плагин. Выбор зависит от того, нужен ли вам точечный контроль или быстрое решение без правок конфигурации.
| Способ | Когда подходит | Минус |
|---|---|---|
| Код в теме или MU-плагине | Нужен контроль на уровне WordPress | Если тема сменится, правило можно потерять |
| Правило на сервере | Нужна блокировка до загрузки WordPress | Требуется доступ к конфигу веб-сервера |
| Плагин безопасности | Нужно быстро и без правок кода | Лишняя зависимость от плагина |
Вариант 1: отключить через код
Если вам нужно именно запретить XML-RPC на уровне WordPress, добавьте фильтр в functions.php дочерней темы или, лучше, в небольшой MU-плагин:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Это отключит сам механизм XML-RPC внутри WordPress. Для большинства сайтов этого достаточно.
Вариант 2: заблокировать доступ на сервере
Если цель — не тратить ресурсы на обработку лишних запросов, можно закрыть xmlrpc.php на уровне Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверная блокировка полезна тем, что запросы не доходят до WordPress вообще. Это снижает нагрузку и убирает часть шума в логах.
Вариант 3: использовать плагин безопасности
Если на сайте уже стоит плагин, который умеет отключать XML-RPC, это допустимый путь. Но я бы не ставил отдельный плагин только ради одной галочки, если можно решить вопрос кодом или конфигом сервера. Лишний плагин — это ещё одна точка обновления и потенциальный конфликт.
Пошаговое решение без лишнего риска
- Проверьте логи и убедитесь, что XML-RPC не используется вашими сервисами.
- Если есть сомнения, сначала отключите его на тестовой копии сайта.
- Выберите способ блокировки: код, сервер или существующий плагин безопасности.
- После изменения очистите кеш страницы и кеш на уровне сервера/CDN, если он есть.
- Проверьте, что
xmlrpc.phpбольше не отвечает успешно.
Если сайт использует только админку WordPress, чаще всего достаточно фильтра xmlrpc_enabled или серверного запрета. Если же у вас есть внешние публикации, сначала замените их на REST API или другой поддерживаемый механизм.
Как проверить, что отключение сработало
Проверка должна быть не «на глаз», а по факту ответа сервера. Откройте в браузере /xmlrpc.php или выполните запрос через curl:
curl -i https://example.com/xmlrpc.phpОжидаемый результат зависит от способа блокировки. При серверном запрете вы обычно увидите 403 Forbidden. Если XML-RPC отключён внутри WordPress, ответ может отличаться, но главное — он не должен вести к успешной обработке метода.
Дополнительно проверьте:
- не ломается ли вход в админку;
- не перестали ли работать формы публикации из сторонних сервисов;
- не появились ли ошибки в логах после изменения;
- не кэшируется ли старый ответ CDN или прокси.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это типичный сценарий. Jetpack и некоторые связанные функции могут использовать XML-RPC для связи с сайтом. Если он вам нужен, не блокируйте интерфейс вслепую. Сначала проверьте, какие модули реально завязаны на этот канал, и только потом принимайте решение.
Добавили правило в тему, а потом сменили шаблон
Если правило лежит в functions.php активной темы, при смене темы оно исчезнет. Для технических ограничений лучше использовать MU-плагин или отдельный мини-плагин, который не зависит от дизайна.
Закрыли файл на сервере, но запросы всё равно идут
Часто причина в том, что блокировка сделана не в том месте: правило попало в неактивный виртуальный хост, а сайт обслуживается другим конфигом. Ещё один вариант — CDN или WAF кэширует старое поведение. В таком случае нужно проверить цепочку полностью: CDN, прокси, веб-сервер, WordPress.
Сломали интеграцию, которая использовала XML-RPC по привычке
Некоторые старые сервисы до сих пор работают через XML-RPC, хотя есть более современные варианты. Если интеграцию нельзя быстро заменить, не отключайте интерфейс до миграции. Лучше сначала перевести публикацию на REST API или другой поддерживаемый способ.
Что выбрать: код, сервер или плагин
Если нужен быстрый и надёжный запрет — серверное правило. Если нужен контроль внутри WordPress и переносимость между окружениями — MU-плагин с фильтром xmlrpc_enabled. Если у вас уже есть плагин безопасности и он закрывает вопрос без конфликта — можно использовать его, но без лишнего зоопарка из нескольких одинаковых функций.
Практические советы по безопасности и производительности
- Не ограничивайтесь только XML-RPC, если у сайта есть другие слабые места: проверьте актуальность ядра, тем и плагинов.
- Если используете WAF или CDN, убедитесь, что правило блокировки не конфликтует с их настройками.
- После изменений посмотрите access log: если запросы к
xmlrpc.phpмассовые, блокировка ещё и снизит шум в логах. - Для повторяемости храните технические ограничения в MU-плагине, а не в теме.
Если вам нужно не просто отключить XML-RPC, а ещё и убрать дубли, мусорные мета-данные и лишние служебные элементы, часть задач можно закрыть через Clearfy Pro. Но даже в этом случае полезно понимать, что именно меняется в коде и на сервере, а не полагаться только на чекбокс в админке.
После внедрения не забудьте зафиксировать решение в документации проекта: где именно отключён XML-RPC, почему это сделано и что нужно проверить при подключении новых сервисов. Это экономит время, когда сайт через полгода начнут дорабатывать другие разработчики.