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