XML-RPC в WordPress часто отключают по одной причине: через него удобно брутфорсить логин и дергать сайт лишними запросами. Но у этой настройки есть нюанс — если просто «запретить всё подряд», можно отрезать Jetpack, старые мобильные клиенты, внешние публикации и часть интеграций. Поэтому задача не в том, чтобы сломать endpoint, а в том, чтобы понять, нужен ли он вообще, и отключить его безопасно.
Когда XML-RPC действительно стоит отключать
Если сайт не использует удаленную публикацию, старые приложения WordPress и интеграции, которые ходят в xmlrpc.php, этот endpoint обычно только увеличивает поверхность атаки. На практике его оставляют включенным по инерции: «вдруг пригодится». Это плохая причина, если вы не можете назвать конкретный сервис, который его использует.
Есть и обратные случаи. Например, если на сайте работает Jetpack, подключены сторонние сервисы публикации или мобильное приложение WordPress, отключение XML-RPC может сломать синхронизацию. Поэтому сначала диагностика, потом изменение.
Диагностика: кто вообще обращается к xmlrpc.php
Самый простой способ — посмотреть логи веб-сервера. Если у вас есть доступ к access log, найдите запросы к /xmlrpc.php. По ним видно, идут ли обращения вообще и откуда.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если сайт за прокси или CDN, запросы могут быть не видны в обычном логе хостинга. Тогда проверьте аналитику безопасности, логи WAF или плагины защиты. Важно не количество запросов само по себе, а наличие легитимных источников:
- Jetpack;
- мобильное приложение WordPress;
- внешние сервисы автопостинга;
- интеграции, которые используют XML-RPC вместо REST API.
Если вы не уверены, временно включите журналирование на стороне сервера или проверьте, не появляются ли ошибки в сервисах, которые должны публиковать контент удаленно.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, где вам удобнее контролировать поведение: в коде, на уровне сервера или через плагин. Ниже — практические варианты без выдуманных трюков.
| Способ | Когда подходит | Минус |
|---|---|---|
| Код в теме или mu-plugin | Нужен точный контроль и понятное поведение | Нужно не забыть про обновления и место подключения |
| Правило на сервере | Есть доступ к Nginx/Apache и нужен быстрый запрет | Можно случайно задеть легитимные интеграции |
| Плагин безопасности | Нужен интерфейс и дополнительные меры защиты | Лишняя зависимость от плагина |
Вариант 1. Отключить через код
Если нужен предсказуемый вариант, добавьте фильтр xmlrpc_enabled. Лучше делать это в небольшом mu-plugin, а не в активной теме: так настройка не исчезнет после смены темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот способ отключает сам XML-RPC на уровне WordPress. Если какой-то сервис продолжит стучаться в xmlrpc.php, он получит отказ, но WordPress не будет обрабатывать запрос.
Вариант 2. Закрыть доступ на уровне сервера
Если вы точно знаете, что XML-RPC не нужен, можно заблокировать сам файл. Для Nginx это обычно делается отдельным location-блоком:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache можно использовать правило в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Серверный запрет полезен тем, что режет запросы раньше, чем они дойдут до WordPress. Это снижает лишнюю нагрузку и убирает часть шума в логах.
Вариант 3. Через плагин безопасности
Если у вас уже стоит плагин, который умеет отключать XML-RPC, можно использовать его, но только если вы понимаете, что именно он делает. Важно не включать одновременно несколько инструментов, которые меняют одно и то же поведение: потом сложно понять, что именно сломало интеграцию.
Из практики удобнее, когда отключение XML-RPC идет вместе с другими мерами: ограничением попыток входа, защитой от брутфорса и чисткой лишних функций. Например, в Clearfy Pro есть набор SEO и технических настроек, которые помогают убрать часть лишнего поведения сайта, но сам выбор способа отключения XML-RPC все равно лучше делать осознанно, а не «на всякий случай».
Пошаговое решение без сюрпризов
- Проверьте, используется ли XML-RPC сейчас: логи, Jetpack, внешние приложения.
- Если интеграций нет, выберите способ отключения: код или сервер.
- Внесите изменение сначала на staging, а не на боевом сайте.
- Проверьте ответ
/xmlrpc.phpи убедитесь, что легитимные сценарии не сломались. - Если что-то перестало работать, верните доступ только для нужного сервиса, а не открывайте endpoint целиком.
Если у вас есть доступ к staging, это лучший момент проверить не только сам endpoint, но и связанные сценарии: публикацию через внешний сервис, синхронизацию с Jetpack и авторизацию в мобильном приложении.
Как проверить, что XML-RPC действительно отключен
Проверка должна быть не «в админке вроде всё работает», а технической. Самый простой тест — запрос к xmlrpc.php должен возвращать отказ или не должен обрабатываться WordPress.
curl -I https://example.com/xmlrpc.phpОжидаемое поведение зависит от способа блокировки. Если вы закрыли файл на сервере, часто будет 403 Forbidden. Если отключили через WordPress-фильтр, ответ может отличаться, но endpoint не должен принимать рабочие XML-RPC вызовы.
Для более прикладной проверки можно отправить тестовый XML-RPC запрос и убедиться, что авторизация не проходит. Если вы не используете этот протокол, достаточно проверить, что:
- в логах больше нет успешных обращений к
xmlrpc.php; - Jetpack и другие нужные интеграции не жалуются;
- внешние сервисы публикации не теряют связь с сайтом;
- нагрузка от повторяющихся запросов исчезла или заметно снизилась.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать Jetpack
Это типичный сценарий, если не проверили зависимости заранее. Решение простое: либо вернуть XML-RPC, либо отказаться от Jetpack-функций, которые его требуют. Не стоит держать endpoint открытым «для всего» только ради одного сервиса, если можно заменить сценарий на REST API или другой способ интеграции.
Поставили и плагин, и серверное правило одновременно
В итоге непонятно, что именно блокирует запрос. Это мешает диагностике и иногда создает ложные ошибки в логах. Сначала оставьте один способ, проверьте результат, потом при необходимости усилите защиту на сервере.
Сломали публикацию из внешнего сервиса
Если сервис использует XML-RPC, его нужно либо перенастроить, либо оставить доступ только для него. Полное отключение без замены — это не оптимизация, а потеря функции.
Ориентируются только на код ответа
403 сам по себе не гарантирует, что проблема решена правильно. Важно проверить, что сайт не принимает XML-RPC запросы и что нужные интеграции не пострадали. Иначе можно получить «защиту», которая ломает рабочий процесс.
Что сделать для безопасности и производительности дополнительно
Отключение XML-RPC — это только один слой защиты. Если цель в снижении атак на вход, добавьте еще несколько практических мер:
- ограничьте попытки входа;
- включите двухфакторную аутентификацию для админов, если это возможно;
- уберите неиспользуемые плагины и темы;
- проверьте, не открыт ли
wp-login.phpдля массового перебора; - следите за логами 403/401, чтобы видеть всплески атак.
Если вам нужен не только запрет XML-RPC, но и более широкая техническая чистка сайта, имеет смысл посмотреть в сторону инструментов, которые закрывают несколько типовых проблем сразу. Но даже в этом случае сначала проверьте, какие функции реально используются на проекте, а какие можно безболезненно убрать.
В сухом остатке логика простая: сначала выясняете зависимости, потом отключаете XML-RPC одним понятным способом, затем проверяете ответ endpoint и рабочие интеграции. Такой порядок экономит время и не превращает защиту в источник новых багов.