XML-RPC в WordPress часто отключают «на всякий случай», а потом удивляются, почему перестал работать мобильный клиент, внешняя публикация или старый интеграционный сервис. На практике задача не в том, чтобы просто закрыть файл xmlrpc.php, а в том, чтобы сначала понять, нужен ли он вообще вашему сайту, и только потом выбрать способ отключения.
Если сайт не использует внешние клиенты, Jetpack в старой схеме, публикацию через сторонние приложения или legacy-интеграции, XML-RPC обычно можно убрать без последствий. Но если у вас есть старые сервисы синхронизации, лучше сначала проверить запросы и только потом резать доступ на уровне WordPress или веб-сервера.
Когда XML-RPC действительно мешает
Сам по себе XML-RPC — не ошибка и не уязвимость, а интерфейс удалённого доступа. Проблемы начинаются, когда он остаётся включённым на сайте, которому он не нужен. Тогда файл xmlrpc.php становится лишней точкой входа для брутфорса и шумных запросов, а в логах появляются повторяющиеся обращения к методам, которые вы не используете.
Типичный сценарий: сайт работает только через админку и REST API, внешних клиентов нет, но в логах видны запросы к /xmlrpc.php. В этом случае отключение оправдано. Если же у вас есть мобильное приложение WordPress, старый десктопный клиент или интеграция, которая до сих пор ходит через XML-RPC, сначала надо подтвердить это по факту.
Что проверить до отключения
- используется ли Jetpack или другой сервис, который может опираться на XML-RPC;
- есть ли мобильные приложения или внешние редакторы для публикации;
- есть ли в логах запросы к
xmlrpc.phpс успешными ответами, а не только сканирование; - нет ли старых интеграций, которые отправляют пинги, создают записи или обновляют комментарии через XML-RPC.
Диагностика: как понять, нужен ли XML-RPC
Самый надёжный способ — посмотреть не догадки, а фактические обращения. Если у вас есть доступ к логам веб-сервера, ищите строки с xmlrpc.php. Важно отличать обычный мусорный трафик от реального использования: сканеры обычно бьют по файлу короткими запросами, а рабочая интеграция делает повторяемые вызовы с понятным паттерном.
Если логов нет, можно временно включить простую диагностику на уровне WordPress и посмотреть, кто обращается к XML-RPC. Для этого удобно повеситься на фильтр xmlrpc_enabled и временно логировать факт вызова. Это не постоянное решение, а способ понять, есть ли живые клиенты.
<?php
add_filter('xmlrpc_enabled', function ($enabled) {
if (defined('WP_DEBUG') && WP_DEBUG) {
error_log('XML-RPC check from: ' . ($_SERVER['REMOTE_ADDR'] ?? 'unknown'));
}
return $enabled;
});Если после этого в логах нет полезных обращений, а только случайные IP и попытки подбора, отключение обычно безопасно. Но если вы видите запросы от конкретного сервиса, его нужно проверить отдельно: иногда внешняя система работает не через REST, а через XML-RPC по старой схеме.
Пошаговое решение: как отключить XML-RPC безопасно
Есть три рабочих подхода: отключить на уровне WordPress, закрыть на уровне веб-сервера или сделать оба шага сразу. Для большинства сайтов достаточно отключения в WordPress. Если сайт часто атакуют или у вас дорогой хостинг с жёсткими лимитами, имеет смысл дополнительно отрезать доступ на сервере.
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Фильтр в WordPress | Нужно быстро и обратимо | Легко проверить и откатить | Запрос всё равно доходит до WordPress |
| Правило на сервере | Нужна жёсткая блокировка | Снижает нагрузку раньше PHP | Нужно править конфиг сервера |
| Плагин безопасности | Нет доступа к коду | Удобно для админов без разработки | Лишняя зависимость от плагина |
Вариант 1: отключить через код
Самый простой и прозрачный способ — вернуть false через фильтр xmlrpc_enabled. Добавьте код в functions.php дочерней темы или в небольшой mu-plugin, если не хотите зависеть от темы.
<?php
add_filter('xmlrpc_enabled', '__return_false');Это отключит XML-RPC на уровне WordPress. Если позже выяснится, что какой-то сервис всё-таки нужен, код можно убрать без побочных эффектов.
Вариант 2: закрыть xmlrpc.php на сервере
Если хотите не пускать запросы даже до загрузки WordPress, добавьте правило в конфигурацию веб-сервера. Для Apache это обычно делается через .htaccess, для Nginx — в конфиге сайта.
Для Apache:
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой вариант полезен, если по логам видно постоянный шум или попытки брутфорса. Но перед внедрением убедитесь, что ни один сервис не зависит от XML-RPC, иначе вы получите не просто 403, а поломку интеграции.
Вариант 3: использовать плагин, если код трогать нельзя
Если на сайте нет нормального доступа к файлам, можно использовать плагин безопасности или настройки хостинга. Это менее гибко, но для типового проекта иногда достаточно. Минус в том, что вы добавляете ещё один слой логики, который нужно обновлять и контролировать.
Как проверить, что решение сработало
После отключения проверьте не только админку, но и сам endpoint. Откройте /xmlrpc.php в браузере или через curl. Ожидаемое поведение зависит от способа блокировки: при отключении через WordPress часто будет ответ с сообщением о том, что XML-RPC недоступен, а при серверной блокировке — 403 Forbidden.
curl -I https://example.com/xmlrpc.phpДальше проверьте реальные сценарии, которые могли зависеть от XML-RPC:
- публикация из внешнего клиента;
- подключение мобильного приложения;
- обновление записей через интеграцию;
- работа Jetpack, если он у вас используется в старой схеме.
Если всё, что вам нужно, продолжает работать, значит отключение прошло без потерь. Если что-то сломалось, не ищите проблему в кэше — сначала проверьте, не ходил ли сервис именно в xmlrpc.php.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестала работать интеграция
Причина почти всегда одна: сервис был завязан на XML-RPC, но это не проверили заранее. Решение — вернуть фильтр или правило на сервере, затем выяснить, можно ли перевести интеграцию на REST API или другой способ авторизации.
Закрыли файл на сервере, но WordPress всё равно отвечает
Так бывает, если правило добавили не в тот блок конфигурации или оно не применяется к нужному виртуальному хосту. Проверьте, что правило действительно попало в активный конфиг, а затем перезагрузите веб-сервер.
Использовали плагин и забыли про него
Плагины для безопасности удобны, но часто создают ложное чувство «всё закрыто навсегда». После обновления темы или миграции сайта проверьте, что плагин всё ещё активен и его настройка не сбросилась.
Смешали отключение XML-RPC и блокировку REST API
Это разные механизмы. Если вы одновременно ограничили и XML-RPC, и REST API, можно случайно сломать редактор, внешние приложения или интеграции. Не закрывайте всё подряд без списка зависимостей.
Практические советы по безопасности и производительности
Если XML-RPC не нужен, отключение — нормальная мера гигиены. Но не стоит считать её полноценной защитой сайта. Брутфорс может идти и через /wp-login.php, а нагрузку создают и другие точки входа. Поэтому после отключения XML-RPC проверьте ещё и базовые вещи: ограничение попыток входа, актуальные обновления ядра и плагинов, корректные права на файлы, отсутствие лишних админов.
С точки зрения производительности серверная блокировка лучше, чем отключение только в WordPress: запрос отсекается раньше, не тратится PHP-процесс и не поднимается весь стек. На небольших сайтах разница может быть незаметной, но на нагруженных проектах это уже имеет смысл.
Если вы ведёте сайт на наборе технических плагинов, имеет смысл держать такие изменения в коде, а не в интерфейсе, чтобы они были версионируемыми и воспроизводимыми. Для этого удобно вынести правило в mu-plugin или в отдельный файл конфигурации, который попадает в репозиторий.
В итоге правильный порядок такой: сначала диагностика, потом отключение, затем проверка реальных сценариев. Это занимает немного больше времени, чем просто поставить галочку в плагине, но зато не ломает рабочие интеграции и не оставляет сайт в полусломанном состоянии.