XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, внешняя публикация, старые интеграции или сервисы автопостинга. Проблема в том, что это не просто лишний файл в корне сайта, а точка входа, которую некоторые плагины и приложения до сих пор используют для удалённого доступа.
Если задача именно в безопасности и снижении лишнего трафика, отключать XML-RPC можно. Но делать это нужно после проверки зависимостей, а не по принципу «поставил код из интернета и забыл».
Когда XML-RPC действительно мешает
Чаще всего его отключают из-за брутфорса, pingback-атак и лишних запросов к /xmlrpc.php. Это нормальный сценарий, если сайт не использует удалённую публикацию и старые внешние клиенты. Но на живом проекте у XML-RPC могут быть вполне рабочие потребители:
- мобильное приложение WordPress;
- Jetpack и похожие сервисы, если они завязаны на удалённый доступ;
- инструменты автопостинга и планировщики публикаций;
- старые интеграции с внешними CMS и десктопными редакторами;
- некоторые мониторинги, которые проверяют доступность сайта через XML-RPC.
Если вы не уверены, кто именно использует этот endpoint, сначала проверьте логи и только потом режьте доступ.
Диагностика: как понять, можно ли отключать XML-RPC
Самый простой путь — посмотреть, есть ли обращения к xmlrpc.php в access-логах веб-сервера или в логах WAF/CDN. Если сайт на Nginx, ищите запросы с этим путём. Если есть Cloudflare или другой прокси, проверьте аналитику запросов там.
Полезно также пройтись по установленным плагинам и внешним сервисам. Если у вас есть что-то из этого списка, XML-RPC может быть нужен:
- публикация через сторонние приложения;
- синхронизация записей между несколькими сайтами;
- автоматическая отправка материалов из внешней системы;
- старые плагины для удалённого управления контентом.
Быстрая проверка через curl
Можно отправить тестовый запрос и посмотреть ответ сервера. Сам по себе ответ не доказывает, что XML-RPC нужен, но помогает понять, открыт ли endpoint:
curl -i https://example.com/xmlrpc.phpЕсли в ответе видите 405, 403 или явную блокировку со стороны WAF — это уже сигнал, что endpoint ограничен. Если приходит стандартная страница WordPress или ответ на POST-запрос, доступ пока открыт.
Для более точной проверки можно отправить минимальный POST-запрос:
curl -s -X POST https://example.com/xmlrpc.php \
-H 'Content-Type: text/xml' \
--data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'Если сервер отвечает ошибкой доступа или блокировкой, это нормально для закрытого XML-RPC. Если возвращается список методов, endpoint доступен.
Что выбрать: плагин, код или серверный запрет
Есть три рабочих подхода. У каждого свой компромисс.
| Подход | Когда подходит | Минус |
|---|---|---|
| Плагин безопасности | Нужно быстро закрыть доступ без правок кода | Добавляет зависимость и не всегда даёт точечный контроль |
| Код в теме или mu-plugin | Нужен предсказуемый результат и контроль в репозитории | Нужно понимать, где именно размещать код |
| Блокировка на уровне сервера | Хотите отрезать запросы до WordPress | Можно случайно задеть легитимные интеграции |
Если у вас обычный сайт без сложных внешних интеграций, лучше всего работает код в mu-plugins или блокировка на сервере. Если сайт обслуживают несколько людей и нужен быстрый переключатель, можно использовать плагин безопасности. Например, в Clearfy Pro есть инструменты для чистки и отключения лишних функций WordPress, но использовать их стоит только после проверки зависимостей, а не вместо неё.
Пошаговое решение: отключаем XML-RPC безопасно
Шаг 1. Проверьте, не нужен ли endpoint
Сначала убедитесь, что сайт не использует удалённую публикацию, мобильное приложение и внешние сервисы. Если есть сомнения, временно ограничьте доступ по IP или через WAF и посмотрите, не появятся ли ошибки у интеграций.
Шаг 2. Добавьте фильтр в mu-plugin
Самый аккуратный вариант — создать файл в wp-content/mu-plugins/disable-xmlrpc.php. Такой код загружается рано и не зависит от темы:
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот способ отключает сам механизм XML-RPC на уровне WordPress. Если какой-то сервис продолжит стучаться в /xmlrpc.php, он получит отказ.
Шаг 3. Дополнительно закройте доступ на сервере
Если хотите отрезать запросы ещё до загрузки WordPress, добавьте правило в конфигурацию веб-сервера. Для Nginx это может выглядеть так:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}На Apache аналогичный эффект обычно делают через .htaccess, но если у вас нет уверенности в конфигурации хостинга, лучше не экспериментировать вслепую. Серверный запрет особенно полезен, когда endpoint активно атакуют и вы хотите снизить нагрузку.
Шаг 4. Проверьте, не сломали ли вы нужный сценарий
После отключения попробуйте выполнить реальные действия, которые могли зависеть от XML-RPC:
- войти в админку через мобильное приложение, если оно используется;
- опубликовать запись через внешний сервис;
- проверить синхронизацию с автопостингом;
- посмотреть, не появились ли ошибки в логах интеграций.
Как проверить, что решение сработало
Проверка должна быть не только технической, но и прикладной. Смотрите на три вещи:
- Запросы к
/xmlrpc.phpбольше не проходят успешно. - В логах нет новых ошибок от нужных сервисов.
- Сайт не начал отдавать лишние 500 или 403 на обычных страницах.
Для быстрой проверки можно повторить curl-запрос после внедрения. Если всё сделано правильно, ответ будет содержать отказ в доступе или пустой результат без выполнения методов XML-RPC.
Если у вас есть мониторинг, проверьте график 4xx/5xx после изменения. Иногда проблема не в самом отключении, а в том, что серверный запрет настроили слишком широко и зацепили не только xmlrpc.php.
Частые ошибки и как их исправить
Отключили XML-RPC, не проверив интеграции
Это самая частая ошибка. Сайт продолжает работать, но внешняя публикация или мобильный клиент перестают синхронизироваться. Исправление простое: временно верните доступ, найдите потребителя по логам и только потом решайте, чем его заменить.
Заблокировали не только XML-RPC, но и лишние пути
Иногда в конфиге сервера копируют слишком широкий блок и случайно ломают другие endpoint'ы. Проверяйте, что правило применено именно к /xmlrpc.php, а не к каталогу или всему корню сайта.
Положились только на плагин безопасности
Плагин может отключить XML-RPC на уровне WordPress, но сам endpoint всё равно будет доступен веб-серверу. Для снижения нагрузки и количества мусорных запросов лучше сочетать фильтр WordPress и серверный запрет.
Скрыли проблему, но не убрали источник атак
Если XML-RPC атакуют массово, полезно смотреть не только на блокировку, но и на общую защиту входа: ограничение попыток логина, WAF, fail2ban, корректные заголовки и актуальные обновления ядра и плагинов. Иначе вы просто поменяете одну точку шума на другую.
Практические советы по безопасности и производительности
Если XML-RPC на сайте не нужен, отключение — разумный шаг. Но не делайте из него единственную меру защиты. Для реального эффекта полезно:
- обновить WordPress, тему и плагины;
- проверить, не открыт ли доступ к админке без ограничений;
- включить ограничение попыток входа;
- убрать неиспользуемые плагины и темы;
- следить за логами 403/404 и всплесками POST-запросов;
- не хранить в коде сайта лишние интеграции, которые можно вынести в отдельный сервис.
Если вы уже используете инструменты для технической чистки сайта, имеет смысл держать отключение XML-RPC в одном наборе с другими мерами: удалением лишних эмодзи, oEmbed, REST-эндпоинтов, если они не нужны, и прочих необязательных запросов. Но каждую такую настройку нужно проверять отдельно, потому что у WordPress слишком много сценариев, где «лишнее» на первый взгляд оказывается рабочим.
В итоге правильный порядок такой: сначала диагностика, потом точечное отключение, затем проверка реальных сценариев. Это занимает немного больше времени, чем бездумно вставить фрагмент кода, зато не приводит к сюрпризам на продакшене.