XML-RPC в WordPress часто отключают не «на всякий случай», а по конкретной причине: лишняя поверхность атаки, шум в логах, попытки брутфорса через xmlrpc.php или конфликт с внешними сервисами, которые этот интерфейс не используют. Если сайт не синхронизируется с мобильным приложением WordPress, Jetpack или сторонним клиентом, блокировка обычно проходит без последствий. Но если интеграции есть, сначала нужно понять, кто именно обращается к XML-RPC.
Когда XML-RPC действительно стоит блокировать
Самый частый сценарий — сайт не использует удалённую публикацию и не принимает запросы от приложений, которым нужен XML-RPC. Тогда файл xmlrpc.php остаётся доступным только как точка входа для лишних запросов. Это не делает сайт уязвимым автоматически, но убирает один из популярных векторов перебора паролей и уменьшает мусор в access-логах.
Если у вас включены:
- мобильное приложение WordPress для публикации;
- Jetpack с удалёнными функциями;
- старые интеграции, работающие через XML-RPC;
- сервисы автопостинга, которые не умеют REST API;
тогда блокировать интерфейс без проверки не стоит. В таких случаях лучше сначала посмотреть, какие запросы реально приходят на /xmlrpc.php.
Диагностика: кто обращается к xmlrpc.php
Перед изменениями откройте access-лог веб-сервера или логи в панели хостинга и найдите обращения к xmlrpc.php. Если там только случайные POST-запросы с разных IP и без полезной нагрузки, блокировка обычно безопасна. Если видите запросы от ваших сервисов, сначала перенесите интеграцию на REST API или отключите её на стороне клиента.
Полезно проверить и сам сайт: иногда плагины безопасности уже блокируют XML-RPC на уровне сервера или WordPress, а вы пытаетесь добавить ещё один слой. В этом случае важно не получить дублирующее правило, которое потом мешает отладке.
Быстрая проверка вручную
Откройте в браузере https://example.com/xmlrpc.php. Если интерфейс доступен, WordPress обычно отвечает сообщением о том, что XML-RPC сервер принимает только POST-запросы. Это не означает, что всё работает безопасно, но подтверждает, что файл доступен извне.
Для более точной проверки используйте POST-запрос. Например, через curl:
curl -i -X POST https://example.com/xmlrpc.phpЕсли блокировка настроена правильно, вы увидите отказ на уровне сервера или WordPress. Если ответ по-прежнему идёт от XML-RPC, правило не сработало или применяется не там, где нужно.
Как заблокировать XML-RPC через PHP
Самый предсказуемый способ — отключить обработку XML-RPC на уровне WordPress. Для этого добавьте код в functions.php дочерней темы или в собственный мини-плагин. Такой вариант удобен, если вы хотите управлять логикой из WordPress, а не из конфигурации сервера.
add_filter( 'xmlrpc_enabled', '__return_false' );Эта строка отключает XML-RPC для WordPress, но не мешает серверу отдавать сам файл. Для большинства задач этого достаточно: запросы перестают обрабатываться на уровне CMS.
Если нужно не просто отключить XML-RPC, а вернуть понятный ответ при обращении к xmlrpc.php, можно добавить более жёсткую блокировку через init:
add_action( 'init', function () {
if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
wp_die( 'XML-RPC disabled.', 'Forbidden', array( 'response' => 403 ) );
}
} );Этот вариант полезен, когда вы хотите явно завершать запросы с кодом 403. Но он всё равно работает уже внутри WordPress, поэтому не заменяет серверную блокировку, если цель — сократить нагрузку ещё до запуска ядра.
Как заблокировать XML-RPC через .htaccess
Если сайт работает на Apache или LiteSpeed с поддержкой .htaccess, можно закрыть доступ к файлу на уровне веб-сервера. Это быстрее, чем обработка в PHP, и не даёт WordPress даже стартовать для таких запросов.
Добавьте правило в корень сайта, рядом с другими директивами:
<Files xmlrpc.php>
Require all denied
</Files>На старых конфигурациях Apache иногда встречается синтаксис для версии 2.2:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>Используйте только тот вариант, который соответствует вашему серверу. Если не уверены, начните с PHP-отключения, а потом уже переносите блокировку на уровень веб-сервера.
Что выбрать: плагин, PHP или серверное правило
Если задача точечная, без плагина обычно проще. Но у каждого подхода есть компромисс.
| Способ | Плюс | Минус | Когда брать |
|---|---|---|---|
| Плагин безопасности | Быстро включить через интерфейс | Лишняя зависимость и ещё один слой логики | Если уже используете плагин и не хотите править код |
PHP-фильтр xmlrpc_enabled | Просто откатить и проверить | WordPress всё равно загружается | Если нужен управляемый вариант без правок сервера |
.htaccess | Блокирует раньше, чем PHP | Работает не на всех серверах и требует аккуратности | Если сайт на Apache/LiteSpeed и нужен жёсткий запрет |
Пошаговое решение без лишних рисков
- Проверьте, есть ли реальные обращения к
xmlrpc.phpв логах. - Убедитесь, что сайт не использует мобильное приложение WordPress, Jetpack или старые интеграции.
- Сначала добавьте
add_filter( 'xmlrpc_enabled', '__return_false' );и проверьте результат. - Если нужен запрет на уровне сервера, перенесите блокировку в
.htaccess. - После изменения протестируйте
/xmlrpc.phpчерез браузер иcurl. - Посмотрите логи ещё раз: запросы должны либо исчезнуть, либо получать 403.
Проверка результата после внедрения
После отключения XML-RPC не ограничивайтесь открытием страницы в браузере. Это слишком слабая проверка. Нужны минимум три действия:
- открыть
/xmlrpc.phpв браузере и убедиться, что файл не отвечает как раньше; - сделать POST-запрос через
curlи посмотреть HTTP-код; - проверить access-лог, чтобы понять, продолжают ли приходить обращения.
Если вы отключали XML-RPC через PHP, а сервер всё равно отдаёт страницу с сообщением WordPress, значит правило не подключилось: код добавили не в ту тему, не в тот плагин или файл был перезаписан обновлением. Если блокировали через .htaccess, но запросы продолжают проходить, проверьте, действительно ли сайт работает на Apache/LiteSpeed и разрешает ли хостинг использовать этот файл.
Частые ошибки и как их исправить
Добавили код в родительскую тему
После обновления темы правило исчезает. Для таких правок используйте дочернюю тему или собственный мини-плагин. Это особенно важно, если сайт живёт на коммерческой теме и обновляется регулярно.
Сломали интеграцию, не проверив зависимости
Если после отключения перестали работать публикации из внешнего клиента или синхронизация с Jetpack, значит XML-RPC был нужен. В этом случае либо возвращайте доступ, либо переносите интеграцию на REST API, если сервис это поддерживает.
Поставили несколько блокировок сразу
Иногда XML-RPC отключают плагином, фильтром в PHP и правилом в .htaccess одновременно. В итоге трудно понять, что именно сломало запрос. Для диагностики оставляйте один способ, а остальные убирайте до завершения проверки.
Проверили только GET-запрос в браузере
XML-RPC работает через POST. Если вы открыли страницу в браузере и увидели ответ WordPress, это ещё не финальная проверка. Нужен именно POST-запрос, иначе можно ошибочно решить, что блокировка не работает или, наоборот, что всё закрыто.
Безопасность и производительность: что ещё учесть
Отключение XML-RPC не заменяет базовую защиту входа в админку. Если у вас слабые пароли, открыт wp-login.php и нет ограничений на попытки входа, одна только блокировка XML-RPC проблему не решит. Но как часть общей гигиены сайта это полезный шаг.
Если вам нужно одновременно чистить сайт от лишних технических сущностей, дубликатов и следов старых настроек, иногда удобнее собрать это в один набор правил и проверок. В экосистеме WPShop для таких задач есть Clearfy Pro: он закрывает часть типовых технических настроек, но использовать его стоит только если вам действительно нужен плагин, а не точечная правка кода. Ссылка без слеша: Clearfy Pro.
Если же задача сводится только к XML-RPC, не усложняйте стек. Один понятный способ отключения, одна проверка результата и один источник правды в логах обычно лучше, чем набор перекрывающих друг друга решений.