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