XML-RPC в WordPress часто включён по умолчанию, но на практике он нужен не каждому сайту. Если вы не пользуетесь мобильным приложением WordPress, внешними сервисами публикации или старыми интеграциями, этот интерфейс лучше ограничить. Причина простая: XML-RPC нередко используют для перебора паролей, массовых запросов и лишней нагрузки на сайт.
При этом отключать его «в лоб» без проверки не стоит. На некоторых проектах через XML-RPC до сих пор работают удалённая публикация, интеграции с приложениями и отдельные сервисы автоматизации. Ниже — как понять, нужен ли он вам, чем отключать и как убедиться, что после изменений ничего не сломалось.
Когда XML-RPC действительно стоит отключить
Отключение оправдано, если у вас обычный сайт на WordPress без внешней публикации через сторонние клиенты. Типичный сценарий: редакторы работают только в админке, комментарии и формы идут через стандартные плагины, а мобильное приложение WordPress не используется.
Признаки, что XML-RPC вам не нужен
- вы не подключали Jetpack для удалённых функций через XML-RPC;
- не публикуете записи из внешних клиентов;
- не используете старые интеграции с сервисами, которым нужен
xmlrpc.php; - в логах видно много обращений к
/xmlrpc.phpбез понятной причины.
Когда лучше не отключать
Если у вас есть мобильная редакция, внешняя автоматизация публикаций или старый сервис, который синхронизирует контент через XML-RPC, сначала проверьте документацию этого сервиса. В некоторых случаях достаточно не отключать интерфейс полностью, а ограничить доступ на уровне сервера или WAF.
Диагностика проблемы: как понять, что XML-RPC создаёт риск или нагрузку
Самый практичный способ — посмотреть, есть ли обращения к xmlrpc.php в логах веб-сервера. Если запросов много, а вы не понимаете их источник, это уже повод для проверки. На хостинге с доступом к логам ищите строки с POST /xmlrpc.php и повторяющиеся IP-адреса.
Ещё один признак — всплеск неудачных попыток входа в админку при отсутствии видимой активности пользователей. XML-RPC часто используют для brute force, потому что один запрос может содержать несколько попыток авторизации.
Проверить доступность интерфейса можно и вручную. Если открыть https://ваш-домен/xmlrpc.php в браузере, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не ошибка, а признак того, что файл доступен извне.
Как отключить XML-RPC: рабочие способы
Есть три нормальных подхода: через код, через сервер и через защитный плагин. Выбор зависит от того, есть ли у вас доступ к конфигурации и нужен ли более мягкий вариант, чем полная блокировка.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в WordPress | Быстро, не зависит от хостинга | Не защищает до загрузки WordPress |
| .htaccess / nginx | Блокирует запросы раньше, чем загрузится сайт | Нужен доступ к серверной конфигурации |
| Плагин безопасности | Удобно для админов без доступа к серверу | Добавляет ещё один слой логики |
Вариант 1: отключить XML-RPC через functions.php или mu-plugin
Если нужен быстрый и понятный способ, добавьте фильтр xmlrpc_enabled. Лучше не править тему напрямую, а использовать mu-plugin или небольшой плагин для сайта. Так настройка не слетит после обновления темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Если хотите оставить XML-RPC включённым только для отдельных сценариев, такой вариант уже не подойдёт. В этом случае лучше ограничивать доступ на сервере или использовать более точечную логику.
Вариант 2: заблокировать xmlrpc.php на уровне сервера
Это более жёсткий и надёжный вариант. На Apache можно закрыть доступ к файлу через .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Для nginx обычно используют отдельное правило в конфигурации сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой способ хорош тем, что запросы отсеиваются до WordPress. Это снижает лишнюю нагрузку и убирает саму точку входа для атак.
Вариант 3: использовать плагин безопасности
Если у вас нет доступа к серверу, можно отключить XML-RPC через плагин безопасности. Но здесь важно смотреть не на название, а на конкретную функцию: плагин должен либо отключать XML-RPC, либо блокировать xmlrpc.php на уровне правил. Если плагин просто «скрывает» проблему, пользы мало.
Для сайтов, где одновременно нужно чистить дубли, лишние мета-данные и технический мусор, иногда удобнее держать отдельный набор настроек в одном инструменте. Например, Clearfy Pro закрывает часть типовых задач по оптимизации и чистке сайта, но решение по XML-RPC всё равно стоит проверять отдельно по документации и фактическому поведению сайта.
Пошаговое решение без лишнего риска
- Проверьте, использует ли кто-то XML-RPC на сайте: мобильное приложение, внешняя публикация, старые интеграции.
- Сделайте резервную копию конфигурации и файлов, если меняете серверные правила.
- Выберите способ блокировки: код, сервер или плагин.
- Внедрите изменение сначала на тестовой копии сайта, если она есть.
- Проверьте доступ к
/xmlrpc.phpи работу обычной авторизации, REST API и публикации записей.
Если вы работаете через код, самый безопасный путь — отдельный mu-plugin. Создайте файл wp-content/mu-plugins/disable-xmlrpc.php и добавьте туда:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Mu-plugin удобен тем, что он не зависит от темы и не требует активации в админке. Для технической настройки это обычно надёжнее, чем правка functions.php.
Как проверить, что отключение сработало
После внедрения проверьте не только сам файл xmlrpc.php, но и побочные эффекты. Это важнее, чем просто увидеть код ответа.
- Откройте
/xmlrpc.phpв браузере: при серверной блокировке должен быть отказ в доступе. - Проверьте, не используются ли внешние публикации или мобильное приложение WordPress.
- Посмотрите логи сервера: обращения к
xmlrpc.phpдолжны либо исчезнуть, либо получать отказ. - Убедитесь, что вход в админку, REST API и обычные формы работают как раньше.
Если вы отключали XML-RPC через фильтр, а файл всё ещё доступен по прямому URL, это нормально: WordPress просто перестанет обрабатывать запросы. Но если вам нужна именно защита от лишних обращений, лучше закрыть файл на уровне сервера.
Частые ошибки и как их исправить
Отключили XML-RPC и сломали внешний сервис
Такое бывает, если сайт использует старую интеграцию или мобильное приложение. Решение простое: верните доступ временно и проверьте, какой именно сервис делает запросы. Без этого легко отключить нужную функцию вместе с ненужной.
Добавили правило в .htaccess, но оно не работает
Чаще всего причина в том, что сайт работает на nginx, а не Apache, или правило стоит не в том месте. На nginx нужен отдельный location-блок, а не .htaccess.
Отключили XML-RPC, но атаки в логах остались
Это нормально: сканеры продолжают стучаться на старый адрес, но теперь запросы должны получать отказ. Если нагрузка всё ещё заметна, проверьте, не обрабатывает ли сервер эти запросы слишком поздно. В таком случае лучше перенести блокировку на уровень веб-сервера или WAF.
Сделали всё через плагин, но забыли проверить обновления
Плагины безопасности полезны, пока они актуальны и не конфликтуют с другими настройками. После обновлений иногда меняются правила или логика фильтрации. Поэтому проверку /xmlrpc.php стоит повторять после крупных обновлений ядра, темы и плагинов.
Практические советы по безопасности и производительности
Если ваша цель — не только убрать лишнюю точку входа, но и снизить поверхность атаки, не ограничивайтесь XML-RPC. Проверьте, не нужно ли вам ещё отключить лишние сервисы, которые не используются на сайте: старые интеграции, неактуальные плагины, лишние публичные эндпоинты.
Для производительности серверная блокировка обычно предпочтительнее, чем обработка запроса уже внутри WordPress. Это особенно заметно на сайтах, которые и так получают много мусорного трафика. Чем раньше запрос отсекается, тем меньше лишней работы делает PHP и база данных.
Если вы ведёте несколько сайтов, имеет смысл оформить такие настройки как стандартный чек-лист для запуска проекта: проверка XML-RPC, REST API, авторизации, кеша и логов. Это экономит время на поддержке и снижает шанс пропустить старую дыру в конфигурации.