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