XML-RPC в WordPress часто выключают «на всякий случай», а потом внезапно ломают мобильные клиенты, внешние публикации или интеграции с сервисами, которые до сих пор используют этот протокол. Если задача не просто закрыть лишнюю поверхность атаки, а сделать это без побочных эффектов, сначала нужно понять, кто именно обращается к /xmlrpc.php.
Когда XML-RPC действительно стоит отключать
Если сайт не использует старые мобильные приложения WordPress, удалённую публикацию через сторонние клиенты и интеграции, завязанные на XML-RPC, то этот файл чаще всего только создаёт лишний риск. На практике его отключают ради снижения шума от брутфорса и уменьшения числа точек входа, которые сканируют боты.
Но есть важная оговорка: отключение XML-RPC не заменяет нормальную защиту входа в админку. Если у вас слабые пароли, открытый wp-login.php и нет ограничений по IP или 2FA, выключение одного файла проблему не решит.
Диагностика: кто использует XML-RPC сейчас
Перед изменениями проверьте логи веб-сервера. Если там есть регулярные запросы к /xmlrpc.php с кодом 200, 401 или 403, это уже сигнал, что файл не пустует. Если запросов нет, но сайт старый или у вас есть внешние сервисы публикации, лучше проверить вручную.
Что смотреть в логах
- частые POST-запросы к
/xmlrpc.php; - повторяющиеся попытки
system.multicall; - ошибки авторизации от внешних клиентов;
- пики запросов с одного IP или из одного диапазона.
Если доступа к логам нет, можно временно открыть файл в браузере. Нормальный ответ WordPress на /xmlrpc.php обычно не выглядит как обычная страница сайта, а при POST-запросах можно увидеть, реагирует ли endpoint вообще. Но для точной диагностики лучше всё же смотреть серверные логи.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, где у вас есть контроль: в коде, на уровне плагина или на уровне веб-сервера. Для большинства проектов достаточно одного из первых двух вариантов.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Прозрачно, легко откатить, не зависит от внешнего плагина | Нужно аккуратно разместить код |
| Плагин безопасности | Быстро для типового сайта | Лишняя зависимость, иногда избыточные функции |
| Правило на сервере | Режет запросы раньше WordPress | Нужен доступ к конфигу сервера |
Вариант 1: отключить через код
Самый прямой способ — убрать сам endpoint и дополнительно запретить доступ к файлу. Для этого удобно использовать mu-plugin, чтобы код не потерялся при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
status_header( 403 );
exit;
}
} );Создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную. Такой вариант хорош тем, что он не зависит от темы и не исчезнет после обновления.
Вариант 2: запретить доступ на уровне сервера
Если сайт работает на Apache, можно закрыть xmlrpc.php через .htaccess. Это полезно, когда вы хотите отрезать запросы ещё до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx правило обычно добавляют в конфигурацию сайта:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Этот способ особенно удобен на высоконагруженных сайтах: ботам не приходится даже запускать WordPress, чтобы получить отказ.
Вариант 3: использовать плагин безопасности
Если у вас уже стоит плагин, который умеет отключать XML-RPC, это допустимый путь для типового сайта. Но не стоит ставить отдельный плагин только ради одной настройки, если ту же задачу можно решить кодом или серверным правилом.
Если в проекте уже используется Clearfy Pro, там есть инструменты для технической чистки и отключения лишних функций WordPress. Это не обязательное решение, но для сайтов, где нужно централизованно управлять «мусорными» возможностями ядра, такой подход бывает удобен. Ссылка: Clearfy Pro.
Пошаговое внедрение без сюрпризов
- Проверьте, есть ли внешние сервисы, которые публикуют в WordPress через XML-RPC.
- Посмотрите логи на обращения к
/xmlrpc.php. - Выберите способ отключения: код, сервер или плагин.
- Внесите изменение сначала на staging-копии сайта.
- Проверьте, не сломались ли мобильные клиенты и интеграции.
- После проверки перенесите изменение на продакшен.
Если нужен быстрый откат
Код в mu-plugins проще всего убрать: удалили файл — функция вернулась. Серверное правило тоже откатывается быстро, но требует доступа к конфигурации. Плагин удобен, если у вас есть админ-доступ, но он добавляет ещё один слой, который нужно обновлять и контролировать.
Как проверить, что решение сработало
После отключения XML-RPC не ограничивайтесь открытием главной страницы. Нужна проверка именно endpoint'а и связанных сценариев.
- Откройте
/xmlrpc.phpв браузере: файл не должен вести себя как рабочий endpoint. - Сделайте POST-запрос к
/xmlrpc.phpи проверьте, что ответ идёт с отказом. - Посмотрите логи веб-сервера: запросы должны получать 403 или не доходить до WordPress.
- Проверьте внешние клиенты и сервисы, если они у вас есть.
Простой тест через curl:
curl -i -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'Если всё отключено корректно, вы не должны получать рабочий ответ XML-RPC с перечнем методов или успешной авторизацией.
Частые ошибки и как их исправить
Отключили XML-RPC, но оставили старый плагин публикации
Некоторые плагины и приложения продолжают пытаться стучаться в xmlrpc.php. В результате вы видите ошибки авторизации или таймауты. Решение простое: либо переводите интеграцию на REST API, либо оставляете XML-RPC включённым только для конкретного сценария.
Поставили плагин, который делает слишком много
Частая ошибка — ради одной функции ставить тяжёлый security-плагин, который меняет десятки настроек сразу. Потом сложно понять, что именно сломало авторизацию, кэш или редактор. Если нужна только блокировка XML-RPC, код или серверное правило обычно чище.
Закрыли доступ на сервере, но не проверили кэш и WAF
Иногда запросы к /xmlrpc.php продолжают проходить через CDN или защиту хостинга, а локально всё выглядит нормально. После внедрения проверьте путь запроса снаружи, а не только из панели хостинга.
Отключили XML-RPC и забыли про безопасность входа
Это не замена защите wp-login.php. Если цель — снизить риск брутфорса, добавьте ограничение попыток входа, 2FA для админов и нормальные пароли. Иначе вы просто убрали один из векторов, но не закрыли остальные.
Что ещё стоит сделать рядом с этой настройкой
Если вы уже чистите техническую поверхность сайта, имеет смысл пройтись по соседним точкам: отключить лишние эмодзи, убрать ненужные embeds, проверить REST API-эндпоинты, которые не используются, и пересмотреть список активных плагинов. Но делать это нужно по одному изменению за раз, иначе потом невозможно понять, что именно повлияло на сайт.
Для проектов, где важна системная техническая чистка, удобнее держать такие настройки в одном месте и документировать их в репозитории или в отдельном mu-plugin. Тогда при переносе сайта между окружениями не придётся вспоминать, где именно была галочка или правило.