XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом удивляются лишним запросам, брутфорсу и странным обращениям к /xmlrpc.php в логах. Если сайт не использует старые внешние публикации, мобильные клиенты WordPress или Jetpack-функции, этот интерфейс обычно можно отключить. Но делать это нужно аккуратно: у части сайтов XML-RPC завязан на рабочие интеграции.
Ниже — практический разбор: как понять, нужен ли вам XML-RPC, чем его отключать, как не сломать интеграции и как проверить результат после внедрения.
Когда XML-RPC действительно стоит отключить
XML-RPC — это отдельная точка входа в WordPress, через которую можно выполнять удалённые действия: публиковать записи, обновлять контент, отправлять пинги и т. д. На современных сайтах этот механизм часто не нужен, потому что те же задачи решаются через REST API, админку или конкретные плагины.
Отключение имеет смысл, если:
- в логах регулярно появляются запросы к
/xmlrpc.php; - сайт не использует Jetpack-функции, завязанные на XML-RPC;
- нет старых мобильных клиентов WordPress;
- нет внешних сервисов, которые публикуют контент через XML-RPC;
- нужно сократить поверхность атаки для брутфорса и pingback-спама.
Если у вас есть сомнения, сначала проверьте, кто и зачем обращается к этому файлу. На живом проекте лучше не отключать интерфейс «вслепую».
Диагностика: как понять, используется ли XML-RPC сейчас
Самый простой способ — посмотреть access-логи веб-сервера. Ищите обращения к /xmlrpc.php. Если запросы идут только от ботов и сканеров, это один сценарий. Если там есть ваши сервисы, мобильные приложения или IP Jetpack, сценарий другой.
Что проверить перед отключением
- есть ли в логах регулярные POST-запросы к
/xmlrpc.php; - используется ли Jetpack и какие его модули реально нужны;
- есть ли сторонние публикационные сервисы;
- не подключён ли старый мобильный клиент WordPress;
- не завязаны ли на XML-RPC интеграции с CRM или планировщиками контента.
Если у вас есть доступ к серверу, можно быстро отфильтровать обращения по логам:
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50На Apache путь к логам может отличаться, но принцип тот же: ищем не сам факт наличия запросов, а их источник и частоту.
Что выбрать: плагин, код или серверное правило
Есть несколько рабочих способов отключить XML-RPC. Выбор зависит от того, насколько жёстко вы хотите закрыть доступ и есть ли у вас доступ к конфигу сервера.
| Подход | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
| Плагин | Быстро, без правок кода | Добавляет ещё один слой логики | Если нужен простой и обратимый вариант |
| Код в теме или mu-plugin | Контролируемо, без лишних зависимостей | Нужно аккуратно внедрять | Если есть доступ к коду сайта |
| Серверное правило | Режет запросы до WordPress | Требует доступа к nginx/apache | Если нужна максимальная жёсткость |
Для большинства проектов достаточно кода в mu-plugin или в отдельном мини-плагине. Это проще сопровождать, чем править тему.
Пошаговое решение через код
Если XML-RPC не нужен, можно отключить его фильтром xmlrpc_enabled. Это стандартный и предсказуемый способ для WordPress.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Лучше не вставлять такой код в functions.php активной темы, если у вас есть возможность вынести его в mu-plugins. Тогда он не исчезнет при смене темы.
Вариант через mu-plugin
Создайте файл wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, её нужно создать вручную. Внутри разместите:
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );После этого WordPress перестанет отвечать на XML-RPC-запросы штатным способом. Но если на сервере есть отдельные правила или плагины безопасности, они могут дополнительно блокировать доступ раньше.
Если нужен более жёсткий вариант
На уровне веб-сервера можно отдавать 403 на запросы к xmlrpc.php. Это полезно, когда вы хотите отсечь лишние обращения до загрузки WordPress. Но здесь важно не переборщить: если у вас есть зависимые сервисы, они перестанут работать сразу.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache логика будет другой, но смысл тот же: запретить доступ к файлу на уровне сервера. Если конфиг сервера вам не знаком, не вносите изменения без теста на staging.
Как не сломать Jetpack и внешние интеграции
Самая частая ошибка — отключить XML-RPC, а потом обнаружить, что перестали работать нужные функции Jetpack или старый сервис автопубликации. Поэтому сначала проверьте, какие модули реально используются.
Если Jetpack нужен только для статистики или отдельных блоков, возможно, XML-RPC можно отключить без последствий. Но если через него идут синхронизация, публикации или удалённые действия, сначала надо найти альтернативу. Для части задач можно перейти на REST API или на прямую интеграцию через вебхуки.
Практический порядок такой:
- сделайте список всех внешних сервисов, которые касаются контента;
- проверьте, есть ли у них режим работы без XML-RPC;
- отключите XML-RPC на staging;
- протестируйте публикацию, обновление и синхронизацию;
- только потом переносите изменение на продакшен.
Проверка результата после внедрения
После отключения нужно убедиться, что WordPress действительно перестал принимать XML-RPC-запросы, а нужные сценарии не пострадали.
Что проверить вручную
- открыть
/xmlrpc.phpв браузере — поведение зависит от способа блокировки, но доступ к функционалу должен быть закрыт; - сделать тестовый POST-запрос к файлу;
- проверить логи сервера на повторные обращения;
- протестировать Jetpack и другие интеграции, если они есть;
- убедиться, что публикация записей и обновление контента работают штатно.
Для теста можно использовать curl:
curl -i -X POST https://example.com/xmlrpc.phpЕсли всё отключено корректно, вы не должны получать рабочий ответ XML-RPC. В зависимости от способа блокировки это может быть 403, 405 или другой отказ, но не нормальный ответ метода WordPress.
Если вы отключали через фильтр, полезно также проверить, что WordPress не сообщает о включённом XML-RPC через сторонние сканеры безопасности и что в логах не осталось успешных обращений.
Частые ошибки и как их исправить
Отключили в теме, а потом сменили шаблон
Если код лежал в functions.php, он исчезнет при смене темы. Для системных ограничений это плохой вариант. Перенесите код в mu-plugin или обычный плагин.
Закрыли XML-RPC на сервере, но забыли про нужный сервис
Такое бывает, когда на сайте есть старый клиент публикации или интеграция, о которой давно не вспоминали. Исправление простое: верните доступ на staging, найдите зависимость и переведите её на другой способ связи.
Поставили несколько плагинов безопасности с одинаковой функцией
Если один плагин отключает XML-RPC, а второй дополнительно фильтрует запросы, диагностика становится сложнее. В итоге непонятно, что именно ломает интеграцию. Лучше оставить один понятный механизм блокировки и документировать его.
Проверили только в браузере
Открытие /xmlrpc.php в браузере не всегда показывает реальную картину. Нужен именно POST-запрос и проверка логов. Иначе можно ошибочно решить, что всё закрыто, хотя endpoint продолжает принимать запросы.
Практические советы по безопасности и производительности
Отключение XML-RPC само по себе не заменяет нормальную защиту входа. Если на сайте слабые пароли, нет ограничений по попыткам входа и не настроена двухфакторная аутентификация, закрытие XML-RPC решит только часть проблемы.
- используйте уникальные пароли и 2FA для админов;
- ограничьте доступ к
wp-login.php, если это уместно для проекта; - следите за логами брутфорса и сканирования;
- не ставьте несколько одинаковых security-плагинов одновременно;
- проверяйте, не создаёт ли плагин лишние запросы к админке и REST API.
Если вам нужно не только закрыть XML-RPC, но и навести порядок в технической части сайта, имеет смысл посмотреть в сторону комплексной чистки и SEO-настроек. Например, у Clearfy Pro есть набор функций для отключения лишнего и уменьшения мусора в WordPress. Но даже в этом случае логику отключения лучше понимать вручную, а не полагаться только на чекбоксы.
Главная идея простая: если XML-RPC не нужен, его лучше убрать. Но сначала проверьте зависимости, затем отключайте через понятный механизм, а после — обязательно тестируйте реальные сценарии, а не только внешний вид страницы.