XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом удивляются лишним запросам, брутфорсу и странным обращениям к /xmlrpc.php. На небольших сайтах это обычно не критично, но если в логах постоянно видны попытки авторизации через XML-RPC или сайт получает много мусорных запросов, отключение этого интерфейса даёт понятный практический эффект: меньше поверхности атаки и меньше лишней нагрузки.
Но здесь есть важная оговорка: XML-RPC всё ещё нужен части интеграций. Например, старым мобильным клиентам WordPress, внешним сервисам публикации и некоторым сценариям Jetpack. Поэтому правильный подход — не «рубить всё подряд», а сначала проверить, используется ли endpoint, и только потом отключать его выбранным способом.
Когда XML-RPC действительно стоит отключать
Сначала смотрим не на советы из интернета, а на факты. Если в access log регулярно встречаются запросы к /xmlrpc.php, особенно с попытками system.multicall или множественными POST-запросами на авторизацию, это уже повод вмешаться. Второй сигнал — сайт не использует внешние клиенты для публикации и не зависит от интеграций, которым нужен XML-RPC.
Признаки, что endpoint не нужен
- Вы публикуете записи только из админки WordPress.
- Jetpack не используется или подключён без функций, завязанных на XML-RPC.
- Мобильное приложение WordPress не используется для публикации.
- В логах есть постоянные POST-запросы к
/xmlrpc.phpс разных IP.
Когда отключать нельзя без проверки
Если сайт подключён к внешним сервисам автопостинга, старым приложениям или нестандартным интеграциям, сначала проверьте документацию этих сервисов. В некоторых случаях достаточно ограничить доступ на уровне WAF или nginx, а не выключать XML-RPC полностью.
Диагностика: используется ли XML-RPC сейчас
Перед изменениями проверьте, отвечает ли endpoint и кто к нему обращается. Это можно сделать и без плагинов: через логи веб-сервера, через браузер и через обычный curl.
curl -I https://example.com/xmlrpc.phpЕсли ответ содержит 200 или 405, endpoint доступен. Это ещё не значит, что он нужен, но показывает, что он открыт для внешних запросов.
Если есть доступ к логам, ищите обращения к xmlrpc.php и частые POST-запросы. На практике полезно смотреть не только количество, но и повторяемость IP и user-agent. Один-два запроса в день — не проблема. Сотни попыток авторизации — уже повод закрывать доступ.
Как отключить XML-RPC: рабочие варианты
Есть три нормальных способа: через код, через сервер и через плагин безопасности. Универсального варианта нет — выбирайте по тому, где у вас проще контролировать изменения.
| Способ | Плюсы | Минусы | Когда выбирать |
|---|---|---|---|
| Код в теме или mu-plugin | Прозрачно, быстро откатывается | Нужно не забыть про обновления темы | Если есть доступ к файлам сайта |
| Правило на сервере | Блокирует запросы раньше WordPress | Зависит от nginx/Apache-конфига | Если нужен жёсткий запрет |
| Плагин безопасности | Удобно для админов без доступа к серверу | Лишняя зависимость от плагина | Если уже используете security-плагин |
Вариант 1: отключить через код
Самый понятный способ — добавить фильтр в functions.php дочерней темы или, лучше, в небольшой mu-plugin. Так правило не потеряется при обновлении темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. Если кто-то обратится к /xmlrpc.php, WordPress не будет обслуживать запрос как обычный API-вызов.
Вариант 2: заблокировать файл на уровне сервера
Если нужен более жёсткий контроль, можно закрыть доступ к xmlrpc.php на уровне веб-сервера. Для Apache часто используют .htaccess, для nginx — отдельное правило в конфиге сайта.
<Files xmlrpc.php>
Require all denied
</Files>Для nginx логика будет другой, но смысл тот же: не отдавать файл вообще. Этот подход полезен, если вы хотите уменьшить количество запросов ещё до загрузки WordPress. Но применять его стоит только тогда, когда вы уверены, что XML-RPC нигде не нужен.
Вариант 3: использовать плагин безопасности
Если на сайте уже стоит плагин безопасности, проверьте, умеет ли он отключать XML-RPC без дополнительных костылей. Это удобно, когда администрированием занимаются не разработчики, а контент-менеджеры. Но не стоит ставить отдельный плагин только ради одной функции, если можно сделать это кодом или серверным правилом.
Пошаговое решение без лишнего риска
- Проверьте логи и убедитесь, что XML-RPC не используется легитимно.
- Сделайте резервную копию файлов и базы.
- Выберите способ отключения: код, сервер или существующий security-плагин.
- Внесите изменение на staging, если он есть.
- Проверьте доступность сайта и связанных интеграций.
- Перенесите изменение на продакшен и ещё раз проверьте endpoint.
Если используете код, лучше вынести его в mu-plugin, а не в тему. Так решение не исчезнет после смены темы и не будет зависеть от шаблона оформления.
Как проверить, что отключение сработало
Проверка должна быть не «на глаз», а по конкретному ответу сервера. После внедрения снова выполните запрос к endpoint:
curl -I https://example.com/xmlrpc.phpЕсли вы блокировали файл на уровне сервера, ожидайте 403 или 404. Если отключали через фильтр WordPress, поведение может отличаться в зависимости от конфигурации, но endpoint не должен работать как раньше.
Дополнительно проверьте:
- не появились ли ошибки в логах PHP и веб-сервера;
- работают ли вход в админку и публикация записей;
- не сломались ли внешние интеграции, если они были;
- уменьшилось ли число запросов к
xmlrpc.phpв access log.
Если после отключения Jetpack или сторонний сервис перестал синхронизироваться, значит, XML-RPC был нужен. В таком случае не возвращайте его «как было» бездумно — лучше ограничьте доступ по IP, если сервис работает с фиксированного адреса, или пересмотрите саму интеграцию.
Частые ошибки и как их исправить
Отключили XML-RPC в теме, а потом обновили шаблон
Это типичная ошибка. Правило исчезает после обновления темы. Перенесите код в mu-plugin или в собственный мини-плагин.
Заблокировали endpoint, но не проверили интеграции
После жёсткой блокировки иногда перестают работать мобильные приложения, внешние публикации и отдельные функции Jetpack. Перед изменением всегда проверяйте, кто реально использует этот канал.
Поставили ещё один плагин ради одной настройки
Лишний плагин — это лишний код, обновления и потенциальный конфликт. Если задача сводится к одному фильтру или одному правилу сервера, не усложняйте стек без причины.
Считали, что отключение XML-RPC заменяет защиту от брутфорса
Это не полноценная замена защите входа. Если у вас слабые пароли, открытая админка и нет лимитов на авторизацию, проблему нужно решать комплексно: 2FA, ограничение попыток входа, нормальные пароли, обновления.
Что ещё стоит проверить рядом с XML-RPC
Если вы уже занялись технической чисткой сайта, имеет смысл посмотреть и на соседние точки риска: /wp-json/, лишние REST-эндпоинты от плагинов, устаревшие плагины с открытыми AJAX-обработчиками, а также дубли и мусорные мета-данные в базе. На практике часто оказывается, что XML-RPC — только один из нескольких открытых каналов, через которые сайт получает лишнюю нагрузку.
Для сайтов, где важна именно техническая гигиена, полезно держать под рукой инструменты, которые убирают дубли, чистят служебные хвосты и помогают не раздувать фронтенд. Если нужен такой набор задач в одном месте, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но и здесь логика та же: сначала понять проблему, потом включать нужную функцию, а не ставить всё подряд.
Если коротко: XML-RPC отключают не «для галочки», а когда он реально не нужен и создаёт лишний риск. Самый безопасный путь — сначала диагностика, потом отключение на уровне кода или сервера, затем проверка логов и интеграций. Такой порядок экономит время на откатах и не ломает рабочие сценарии.