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