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