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