XML-RPC в WordPress часто оставляют включенным «на всякий случай», а потом получают лишнюю поверхность атаки: перебор паролей, pingback-спам и шум в логах. Если вы не пользуетесь мобильным приложением WordPress, Jetpack, внешними публикациями через XML-RPC или старой интеграцией, этот интерфейс обычно можно отключить без потерь.
Но отключать его вслепую не стоит. Сначала нужно понять, используется ли он у вас вообще, а потом выбрать способ: через плагин, через код или на уровне сервера. Ниже — рабочая схема без лишней магии.
Когда XML-RPC действительно мешает
Сам по себе файл xmlrpc.php не является уязвимостью, но он удобен для автоматизированных атак. Особенно если на сайте слабые пароли, нет ограничения попыток входа и включены pingback/trackback. В логах это обычно выглядит как частые POST-запросы к /xmlrpc.php с разными логинами и длинными телами запроса.
Типичные признаки проблемы
- в логах много запросов к
xmlrpc.phpс кодами 200 или 403; - на сайте появляются попытки входа с разных IP;
- нагрузка растет без видимой причины, хотя обычный трафик небольшой;
- в комментариях или уведомлениях всплывает pingback-спам;
- вы не используете функции, завязанные на XML-RPC.
Если у вас подключен Jetpack или вы публикуете записи через мобильное приложение WordPress, сначала проверьте, не сломается ли нужный сценарий. В противном случае отключение можно делать сразу.
Диагностика: нужен ли вам XML-RPC
Самая частая ошибка — отключить интерфейс, а потом удивляться, что перестала работать синхронизация с внешним сервисом. Поэтому сначала проверьте реальные зависимости.
Что проверить перед изменением
- используете ли вы мобильное приложение WordPress;
- подключен ли Jetpack и какие его модули реально нужны;
- есть ли внешние сервисы публикации или автопостинга, которые работают через XML-RPC;
- не завязаны ли на него старые интеграции, которые давно никто не трогал;
- нет ли в логах запросов от легитимных IP, которые вы узнаете.
Если доступа к логам нет, можно хотя бы временно посмотреть, кто обращается к /xmlrpc.php через панель хостинга или WAF. Для небольшого сайта этого обычно достаточно.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, что у вас уже стоит и насколько глубоко вы хотите вмешиваться в стек. Для большинства сайтов достаточно одного из первых двух вариантов.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Плагин | Быстро, без правки кода | Дополнительный плагин в системе | Если нужен простой и понятный контроль |
| Код в теме или mu-plugin | Без лишних зависимостей | Нужно аккуратно обновлять и не потерять правку | Если вы управляете кодовой базой |
| Правило на сервере | Блокирует запросы раньше WordPress | Нужно понимать конфиг веб-сервера | Если нужен жесткий запрет и минимальная нагрузка |
Вариант 1: отключение через код
Если вы не хотите ставить отдельный плагин, добавьте фильтр в functions.php дочерней темы или, лучше, в mu-plugin. Так настройка не потеряется при смене темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );
Этот вариант отключает сам XML-RPC-интерфейс. Если у вас есть зависимости, они перестанут работать сразу, поэтому сначала проверьте сценарии из диагностики выше.
Вариант 2: блокировка на уровне сервера
Если вы хотите не просто отключить функциональность, а вообще не отдавать файл наружу, можно закрыть доступ на уровне веб-сервера. Для Apache подойдет правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>
Для Nginx обычно используют отдельное правило в конфиге сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Такой способ полезен, если вы хотите отсечь лишние запросы до того, как они дойдут до WordPress. Но если у вас есть легитимный клиент, который использует XML-RPC, он тоже перестанет работать.
Вариант 3: плагин для точечного контроля
Если на сайте уже есть плагин безопасности или оптимизации, иногда проще включить блокировку там, чем добавлять еще один кусок кода. Но смотрите, чтобы плагин не делал больше, чем вам нужно. Для этой задачи достаточно именно отключения XML-RPC, а не набора «антиспам»-функций, которые потом сложно разбирать при отладке.
Если вы используете Clearfy Pro, проверьте, что включаете именно отключение XML-RPC и не смешиваете его с другими настройками чистки сайта: https://wpshop.ru/plugins/clearfy?utm_source=wpkeys.ru&utm_medium=article&utm_campaign=otkljuchit-xmlrpc-wordpress-i-zashchitit-sajt-ot-bruteforsa
Что делать, если XML-RPC нужен частично
Иногда отключить его полностью нельзя. Например, Jetpack нужен для части сайта, а внешние публикации — нет. В таком случае лучше не рубить все подряд, а ограничить сопутствующие риски: закрыть pingback, усилить авторизацию и убрать лишние точки входа.
Минимальный набор мер
- отключить pingback/trackback, если они не используются;
- ограничить попытки входа;
- включить двухфакторную аутентификацию для админов;
- проверить, что REST API не открыт лишним плагинам без необходимости;
- убрать слабые пароли и старые учетные записи.
Если вам нужен именно антиспам и чистка технических дублей, иногда полезнее решать задачу комплексно через набор настроек оптимизации, а не только через один XML-RPC-файл.
Проверка результата после внедрения
После отключения важно не просто «посмотреть, что сайт открывается», а проверить конкретные сценарии.
Чек-лист проверки
- откройте
/xmlrpc.phpв браузере или черезcurlи убедитесь, что доступ закрыт или интерфейс не отвечает как раньше; - проверьте вход в админку обычным способом;
- если используете Jetpack или мобильное приложение, протестируйте их отдельно;
- посмотрите логи сервера: количество обращений к
xmlrpc.phpдолжно снизиться или уйти в 403/404; - проверьте, не выросло ли число ошибок в журнале PHP или веб-сервера.
Для быстрой проверки можно использовать curl:
curl -I https://example.com/xmlrpc.php
Если вы блокировали файл на уровне сервера, ожидайте 403. Если отключали через фильтр WordPress, поведение может отличаться в зависимости от конфигурации и кэша, поэтому смотрите не только код ответа, но и логи.
Частые ошибки и как их исправить
Отключили XML-RPC, но оставили pingback-спам
Это происходит, когда блокируют только xmlrpc.php, но не проверяют комментарии и старые записи. Если спам идет через другие механизмы, нужно отдельно отключить pingback/trackback и проверить настройки обсуждения.
Сломали Jetpack или мобильное приложение
Значит, перед отключением не проверили зависимости. В этом случае верните доступ, а потом либо оставьте XML-RPC включенным, либо ограничьте его точечно через серверные правила и дополнительные меры защиты.
Добавили правило в тему и потеряли его после обновления
Код в functions.php основной темы — плохое место для таких правок. Используйте дочернюю тему или mu-plugin. Иначе при обновлении вы снова получите открытый интерфейс.
Поставили несколько плагинов безопасности, которые конфликтуют между собой
Если один плагин блокирует XML-RPC, а другой пытается его «оптимизировать» или логировать, можно получить лишние ошибки и шум в админке. Для одной задачи лучше один ответственный механизм.
Практика по безопасности и производительности
Отключение XML-RPC не заменяет базовую защиту. Это только один слой. Если сайт регулярно атакуют, проверьте еще и вход в админку, права пользователей, обновления ядра и плагинов, а также кэширование страниц. На небольших сайтах именно эти вещи дают заметный эффект без сложной настройки.
Если вы хотите уменьшить количество технического мусора на сайте, имеет смысл смотреть на проблему шире: отключать ненужные сервисы, убирать лишние эндпоинты и не держать включенным то, чем вы не пользуетесь. В WordPress это особенно важно, потому что старые интеграции часто остаются незаметными до первого инцидента.
Итог простой: если XML-RPC вам не нужен, отключайте его осознанно и проверяйте зависимости. Если нужен частично — ограничивайте риск, а не надеясь, что «и так пронесет».