Как отключить XML-RPC и защитить WordPress от брутфорса

Автор: Николай Панин | Опубликовано: 21.08.2026

Если на сайте не используются мобильное приложение WordPress, внешние сервисы публикации и старые интеграции, XML-RPC чаще всего только расширяет поверхность атаки. Самый частый сценарий — массовые попытки подбора паролей через /xmlrpc.php, которые в логах выглядят как поток запросов с методом system.multicall или обычным wp.getUsersBlogs.

Отключать XML-RPC имеет смысл не «на всякий случай», а когда вы понимаете, что он не нужен. Если нужен Jetpack, удалённая публикация или синхронизация через сторонний софт, сначала проверьте зависимости. В остальных случаях endpoint можно закрыть без заметного влияния на обычную работу сайта.

Когда XML-RPC действительно мешает

Проблема обычно проявляется не в админке, а на уровне сервера и безопасности:

в логах много POST-запросов к xmlrpc.php;
идут попытки перебора логина и пароля без перехода на wp-login.php;
нагрузка растёт из-за повторяющихся запросов с system.multicall;
WAF или модуль защиты уже блокирует часть запросов, но трафик всё равно идёт;
некоторые хостинги помечают сайт как атакуемый и включают дополнительные ограничения.

Что проверить до отключения

Сначала убедитесь, что XML-RPC не используется в рабочих сценариях. Проверьте:

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

Если сомневаетесь, временно ограничьте доступ к endpoint на уровне сервера и посмотрите, не появятся ли ошибки в рабочих процессах. Это безопаснее, чем сразу ломать функциональность на продакшене.

Диагностика: как понять, что атака идёт через xmlrpc.php

В access log обычно видно повторяющиеся POST-запросы к одному и тому же файлу. Примерно так это выглядит в логах Nginx:

203.0.113.10 - - [21/Aug/2026:10:12:44 +0000] "POST /xmlrpc.php HTTP/1.1" 200 182 "-" "Mozilla/5.0"
203.0.113.10 - - [21/Aug/2026:10:12:45 +0000] "POST /xmlrpc.php HTTP/1.1" 200 182 "-" "Mozilla/5.0"
198.51.100.24 - - [21/Aug/2026:10:12:47 +0000] "POST /xmlrpc.php HTTP/1.1" 200 182 "-" "Mozilla/5.0"

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

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

На shared-хостинге обычно достаточно панели логов или отчёта модуля безопасности. Важен не только факт обращений, но и их частота: единичный запрос — это нормально, поток однотипных POST — уже повод закрывать endpoint.

Пошаговое решение: как отключить XML-RPC без плагина

Самый надёжный способ — запретить обработку XML-RPC на уровне WordPress. Для этого добавьте код в functions.php дочерней темы или в собственный мини-плагин. Вариант через дочернюю тему подходит для небольших сайтов, но для постоянной защиты лучше отдельный mu-plugin.

Вариант 1. Отключить XML-RPC через фильтр

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

Это простой и рабочий способ: WordPress перестанет принимать XML-RPC-запросы, а обычная работа сайта не изменится. Но если сервер всё равно отдаёт xmlrpc.php с кодом 200, атакующий будет продолжать стучаться в endpoint, просто без доступа к функциональности. Поэтому лучше дополнить это блокировкой на уровне веб-сервера.

Вариант 2. Закрыть xmlrpc.php на уровне Nginx

Если сайт работает на Nginx, добавьте отдельное правило в конфигурацию сайта:

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

Такой вариант обрывает запрос ещё до PHP. Это полезно, если атака идёт массово и вы хотите снизить нагрузку на PHP-FPM. После изменения конфигурации не забудьте проверить синтаксис и перезагрузить Nginx.

nginx -t
systemctl reload nginx

Вариант 3. Ограничить доступ через Apache

Если сайт работает на Apache, правило можно добавить в .htaccess или конфигурацию виртуального хоста:

<Files "xmlrpc.php">
    Require all denied
</Files>

Этот вариант тоже блокирует прямой доступ к файлу. Если у вас смешанная инфраструктура или прокси перед Apache, проверьте, что правило применяется именно на том уровне, где запросы реально доходят до сайта.

Что выбрать: код WordPress, сервер или плагин

Способ	Плюсы	Минусы	Когда использовать
Фильтр `xmlrpc_enabled`	Быстро, без правок сервера	Запросы всё ещё доходят до PHP	Если нет доступа к конфигу веб-сервера
Nginx/Apache	Снимает нагрузку раньше PHP	Нужен доступ к конфигу	Для продакшена и защиты от брутфорса
Плагин безопасности	Удобно для админов без доступа к серверу	Дополнительный код и зависимости	Если уже используете security-плагин

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

Проверка результата после внедрения

После отключения важно не ограничиться «вроде работает». Проверьте несколько вещей:

открывается ли /xmlrpc.php напрямую в браузере или через curl;
нет ли ошибок у интеграций, которые вы считали неиспользуемыми;
снизилось ли число POST-запросов к endpoint в логах;
не появились ли новые ошибки в журнале PHP или веб-сервера.

Проверка через curl выглядит так:

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

Ожидаемый результат зависит от способа блокировки. При серверном запрете это может быть 403 или нестандартное закрытие соединения. При отключении через WordPress запрос может доходить до PHP, но endpoint не должен выполнять XML-RPC-методы.

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

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

Отключили XML-RPC, но атаки в логах остались

Это нормально, если вы закрыли только WordPress-слой. Запросы всё ещё приходят, но уже не обрабатываются. Если хотите убрать и сам трафик на PHP, блокируйте xmlrpc.php на уровне Nginx или Apache.

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

Значит, XML-RPC был нужен. В таком случае не отключайте его полностью. Лучше ограничьте доступ по IP, если это возможно, или используйте более узкую серверную защиту против брутфорса.

Добавили правило в `.htaccess`, но оно не сработало

Частая причина — сайт работает не на Apache, а на Nginx, либо .htaccess не читается из-за настроек хостинга. Проверьте стек сервера и применяйте правило на том уровне, который реально обрабатывает запрос.

После правок появилась ошибка 500

Обычно это синтаксическая ошибка в конфиге или неверно вставленный PHP-код. Для PHP-фильтра проверьте файл на лишние символы, а для Nginx — прогоните nginx -t перед перезагрузкой.

Практика безопасности: что ещё стоит сделать рядом с XML-RPC

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

ограничить число попыток входа в админку;
включить двухфакторную авторизацию для администраторов;
использовать сложные уникальные пароли;
проверить, не открыт ли wp-login.php для массовых попыток без ограничений;
следить за журналами доступа хотя бы на уровне хостинга.

Если нужен более широкий набор мер по чистке и снижению дублей в WordPress, иногда удобнее закрывать несколько технических проблем сразу через специализированные плагины вроде Clearfy Pro: он помогает убрать часть лишнего технического шума и упростить обслуживание сайта. Но для XML-RPC отдельное точечное правило всё равно остаётся самым прозрачным вариантом.

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