Как запретить XML-RPC запросы в WordPress через .htaccess и PHP

XML-RPC в WordPress часто отключают «на всякий случай», но на живом сайте это лучше делать не вслепую. Если у вас не используются мобильное приложение WordPress, внешние публикации через старые клиенты или интеграции, которые опираются на xmlrpc.php, можно точечно закрыть этот вход и убрать лишний вектор атак. Если же интеграции есть, лучше сначала понять, кто именно ходит в XML-RPC, а уже потом блокировать.

Когда блокировка XML-RPC действительно нужна

Типичный сценарий — сайт получает много запросов к /xmlrpc.php с перебором логинов, а в логах видно постоянные обращения без полезной нагрузки. Второй сценарий — сайт работает как обычный блог или корпоративный ресурс, и XML-RPC не используется вообще. В таком случае отключение не ломает публичную часть сайта, но снижает шум в логах и убирает один из популярных способов брутфорса.

Но есть и обратная сторона: некоторые внешние сервисы и старые приложения до сих пор используют XML-RPC для публикации и синхронизации. Если вы просто заблокируете файл на сервере, такие интеграции перестанут работать без явной ошибки в интерфейсе WordPress. Поэтому сначала полезно проверить фактическое использование.

Диагностика: используется ли xmlrpc.php сейчас

Начните с логов веб-сервера. Ищите обращения к /xmlrpc.php и посмотрите, это единичные запросы или постоянный поток. Если у вас есть доступ к access log, достаточно простого фильтра по пути файла.

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

Если запросы идут регулярно, обратите внимание на IP-адреса, user-agent и коды ответа. Массовые попытки обычно выглядят как серия POST-запросов с одинаковым шаблоном. Если же вы видите обращения от конкретного сервиса, который нужен бизнесу, блокировку придется делать аккуратно или заменить способ интеграции.

Еще один практический тест — временно переименовать правило блокировки на тестовом стенде и проверить, не зависят ли от XML-RPC:

• мобильное приложение WordPress;
• старые клиенты публикации;
• внешние сервисы автопостинга;
• интеграции, которые отправляют контент по XML-RPC.

Что выбрать: серверная блокировка или код в WordPress

Если задача именно техническая и вы контролируете сервер, лучше блокировать на уровне веб-сервера. Если нужен более мягкий вариант или вы не хотите трогать конфиг хостинга, подойдет PHP-решение.

Пошаговое решение через .htaccess

Для Apache можно закрыть доступ к xmlrpc.php отдельным правилом. Это самый прямой способ, если сайт работает на Apache и у вас есть доступ к .htaccess.

<Files xmlrpc.php>
    Require all denied
</Files>

Если сервер старый и использует Apache 2.2, вместо Require all denied может понадобиться классический синтаксис:

<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

После сохранения проверьте, что файл действительно недоступен извне. В ответе должен быть 403 Forbidden, а не редирект на главную и не 200 OK.

Если сайт на Nginx

Для Nginx правило добавляется в конфигурацию сайта, а не в .htaccess. Пример:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

После изменения конфигурации не забудьте проверить синтаксис и перезагрузить Nginx. На практике это важнее самого правила: одна лишняя скобка может уронить конфиг сайта.

Пошаговое решение через PHP без правки сервера

Если вы не хотите трогать конфигурацию веб-сервера, можно отключить XML-RPC через WordPress. Это удобно, когда решение нужно развернуть как часть небольшого mu-plugin или в собственном плагине.

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

Такой вариант отключает XML-RPC на уровне WordPress. Запросы будут доходить до сайта, но сам механизм ответит отказом. Для большинства обычных сайтов этого достаточно.

Если нужно не просто отключить функциональность, а еще и вернуть 403 для прямого обращения к файлу, можно добавить отдельную проверку:

<?php
add_action( 'init', function () {
    if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
        status_header( 403 );
        exit;
    }
} );

Этот вариант стоит использовать аккуратно. Он не заменяет серверную блокировку, а лишь закрывает обработку внутри WordPress. Для сайтов с высокой нагрузкой лучше все же отрезать запросы раньше.

Проверка результата после внедрения

После настройки откройте /xmlrpc.php в браузере или проверьте через curl. Для серверной блокировки ожидается 403 без ответа WordPress. Для PHP-варианта тоже не должно быть обычной страницы WordPress или XML-RPC-ответа.

curl -I https://example.com/xmlrpc.php

Полезно проверить и логи. Если блокировка настроена правильно, количество обращений к xmlrpc.php в access log либо исчезнет, либо будет заканчиваться отказом на уровне сервера. Если вы отключали XML-RPC через PHP, убедитесь, что в error log нет новых предупреждений после тестового запроса.

Отдельно проверьте, не сломались ли внешние сценарии:

• публикация из мобильного приложения WordPress;
• автопостинг из внешнего сервиса;
• интеграции старых плагинов, которые используют XML-RPC;
• вебхуки и REST API — они должны продолжать работать, это разные механизмы.

Частые ошибки и как их исправить

Блокируют не тот файл

Иногда пытаются закрыть весь каталог или ставят слишком широкое правило, после чего начинают ломаться другие запросы. Блокировать нужно именно xmlrpc.php, а не весь корень сайта.

Путают XML-RPC и REST API

Отключение XML-RPC не отключает REST API. Если после изменения перестали работать блоки редактора, мобильное приложение или интеграции на REST, причина, скорее всего, в другом правиле безопасности или в плагине.

Добавляют правило в неправильное место

В Apache правило должно попадать в активный .htaccess сайта. В Nginx его нельзя вставить в .htaccess — там нужен конфиг виртуального хоста. Это частая причина, почему «ничего не изменилось».

Не проверяют сторонние интеграции

Если сайт подключен к внешнему сервису публикации, блокировка может отрубить автоматизацию. Перед внедрением проверьте, кто реально обращается к XML-RPC, и только потом закрывайте доступ.

Практические советы по безопасности и производительности

Если XML-RPC вам не нужен, серверная блокировка предпочтительнее: она уменьшает лишнюю нагрузку и сокращает поверхность атаки. Но не стоит воспринимать ее как полноценную защиту от брутфорса сама по себе. Пароли администратора, лимиты попыток входа и актуальные обновления WordPress остаются обязательными.

Для сайтов, где нужен только один конкретный сценарий, иногда разумнее не отключать XML-RPC полностью, а ограничить доступ на уровне сети или WAF. Это особенно полезно, если интеграция зависит от старого протокола, но приходит с предсказуемого IP.

Если вы ведете несколько сайтов, удобно вынести блокировку в маленький mu-plugin или в общий серверный шаблон. Так правило не потеряется после обновления темы и не зависит от конкретного плагина.

Когда нужен более широкий набор технических настроек для чистки сайта, отключения дублей и контроля лишних запросов, можно посмотреть в сторону Clearfy Pro. Но если задача сводится только к XML-RPC, отдельное правило в сервере или небольшой код обычно проще и прозрачнее.