XML-RPC в WordPress часто оставляют включенным по умолчанию, а потом удивляются лишним запросам, попыткам подбора пароля и странной нагрузке на сервер. Сам по себе этот интерфейс не «плохой», но если вы не пользуетесь приложением WordPress для телефона, внешними публикациями или старым удалённым API, его обычно проще отключить. Важно сделать это аккуратно: не сломать нужные интеграции и не ограничиться только визуальной блокировкой на уровне плагина.
Когда XML-RPC действительно стоит отключать
Сначала проверьте, используется ли он вообще. На небольших сайтах ответ часто отрицательный: редакторы работают из админки, мобильное приложение не нужно, сторонние сервисы публикуют через REST API или напрямую через плагин. В таком случае XML-RPC только расширяет поверхность атаки.
Типичные признаки, что он вам не нужен
- в логах много запросов к
/xmlrpc.phpс разных IP; - в панели безопасности плагин показывает попытки brute force через XML-RPC;
- вы не используете Jetpack, старые мобильные клиенты WordPress или внешнюю публикацию через XML-RPC;
- сайт работает только как обычный блог или корпоративный сайт без удалённого редактирования.
Если у вас есть интеграция, которая действительно опирается на XML-RPC, отключать его вслепую не стоит. Сначала выясните, что именно его вызывает: мобильное приложение, старый плагин автопостинга или внешний сервис синхронизации.
Диагностика проблемы: как понять, что XML-RPC уже атакуют
Самый простой способ — посмотреть логи веб-сервера или отчёты security-плагина. Часто атака выглядит как серия POST-запросов к xmlrpc.php с попытками метода system.multicall. Этот метод удобен для перебора паролей, потому что позволяет упаковать много попыток в один запрос.
Если у вас есть доступ к access log, можно быстро отфильтровать обращения:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50На Apache путь к логам может отличаться, но смысл тот же: ищете частые POST-запросы, повторяющиеся IP и одинаковые user-agent. Если таких запросов много, отключение XML-RPC даст заметный эффект не только по безопасности, но и по лишней нагрузке.
Ещё один полезный тест — проверить ответ самого файла. Если открыть /xmlrpc.php в браузере, WordPress обычно возвращает сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не ошибка, а нормальное поведение. Но если вы решили его отключить, дальше нужно убедиться, что файл перестал отвечать как рабочая точка входа.
Как отключить XML-RPC: сравнение подходов
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Контроль на уровне WordPress, легко проверить | Нужно не забыть перенести при смене темы |
| Плагин безопасности | Быстро включить без кода | Зависимость от настроек плагина, лишняя нагрузка |
| Блокировка на уровне сервера | Отсекает запросы раньше WordPress | Нужен доступ к конфигу Nginx/Apache |
Для большинства проектов лучший вариант — сочетание серверной блокировки и короткого кода в mu-plugin. Так вы не зависите от темы и не оставляете файл доступным через WordPress-обработку.
Пошаговое решение через код
Если нужен управляемый вариант внутри WordPress, добавьте фильтр xmlrpc_enabled. Это штатный хук, который отключает XML-RPC без выдуманных обходов и костылей.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Лучше положить этот код не в functions.php, а в маленький must-use плагин. Тогда он не исчезнет после смены темы.
Пример файла wp-content/mu-plugins/disable-xmlrpc.php:
<?php
/**
* Disable XML-RPC for this site.
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Если папки mu-plugins нет, создайте её вручную. WordPress подхватит файл автоматически, без активации в админке.
Дополнительная защита на уровне сервера
Если у вас Nginx, можно закрыть доступ к файлу напрямую. Это не заменяет отключение в WordPress, но уменьшает число лишних обращений до PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Перед применением серверного правила проверьте, не обслуживает ли сайт старые интеграции. Если сомневаетесь, сначала отключите XML-RPC через фильтр и понаблюдайте за логами.
Как проверить, что решение сработало
Проверка должна быть не формальной, а практической. Откройте /xmlrpc.php и посмотрите, что возвращает сервер. После блокировки на уровне Nginx или Apache вы должны получить 403 Forbidden или аналогичный отказ. Если отключали только через фильтр WordPress, ответ может отличаться, но сам API работать не должен.
Дальше проверьте три вещи:
- в логах больше нет успешных обращений к XML-RPC;
- security-плагин перестал фиксировать попытки brute force через этот endpoint;
- мобильное приложение WordPress и внешние сервисы, если они были, не потеряли нужную функцию.
Если после отключения что-то сломалось, значит XML-RPC использовался неявно. В таком случае не возвращайте его целиком, а сначала найдите конкретный сервис и оцените, можно ли заменить его REST API или прямой интеграцией через плагин.
Частые ошибки и как их исправить
Отключили в теме, а потом сменили шаблон
Это самая частая ошибка. Код в functions.php живёт только пока активна тема. После обновления или смены шаблона защита исчезает. Для системных ограничений используйте mu-plugin или серверный конфиг.
Заблокировали файл, но оставили старую интеграцию
Иногда сайт продолжает работать, пока не приходит очередная синхронизация из внешнего сервиса. Поэтому после блокировки обязательно проверьте все интеграции: мобильные приложения, автопостинг, удалённые редакторы, старые плагины публикации.
Поставили плагин безопасности и забыли про сервер
Плагин может скрыть симптом, но не убрать сам endpoint. Если атака идёт массово, лучше отрезать запросы на уровне веб-сервера и дополнительно отключить XML-RPC в WordPress.
Сломали REST API вместо XML-RPC
Иногда администраторы путают эти механизмы и начинают ограничивать всё подряд. XML-RPC и REST API — разные вещи. Если вам нужен мобильный редактор или интеграция с современным сервисом, REST API может остаться рабочим, даже когда XML-RPC уже закрыт.
Что делать для безопасности и производительности после отключения
Если XML-RPC был источником шума в логах, после отключения имеет смысл проверить и соседние точки входа: wp-login.php, неиспользуемые админ-аккаунты, слабые пароли, двухфакторную аутентификацию. Отключение одного endpoint не заменяет базовую гигиену доступа.
- ограничьте число попыток входа;
- включите 2FA для администраторов;
- убедитесь, что резервные копии делаются регулярно;
- проверьте, нет ли старых плагинов, которые тоже открывают лишние API-точки;
- посмотрите, не создаёт ли сайт лишнюю нагрузку из-за cron или внешних пингов.
Если вам нужен более широкий аудит технических дублей, мусорных настроек и лишних запросов, иногда удобнее пройтись по сайту комплексно: убрать неиспользуемые функции, проверить индексацию служебных страниц и сократить число точек входа. В таких задачах полезны инструменты вроде Clearfy Pro, если они подходят под ваш стек и вы понимаете, что именно отключаете.
Смысл простой: XML-RPC — это не тот случай, где нужно «на всякий случай оставить». Если он не нужен, его лучше отключить, проверить логи и закрыть вопрос на уровне WordPress и сервера. Тогда вы уменьшите риск брутфорса и уберёте лишний шум без побочных эффектов.