Как запретить XML-RPC в WordPress через .htaccess и PHP без лишних поломок

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

Когда XML-RPC действительно стоит отключать

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

Что проверить перед изменением конфигурации

• используется ли Jetpack для синхронизации или публикации;
• подключены ли мобильные приложения WordPress;
• есть ли внешние сервисы, которые публикуют записи через XML-RPC;
• есть ли в логах запросы к xmlrpc.php от ваших IP или доверенных сервисов;
• не закрыт ли уже этот файл на уровне хостинга, WAF или CDN.

Диагностика: как понять, нужен ли вам XML-RPC

Самый простой способ — посмотреть access-логи веб-сервера. Если у вас Nginx или Apache, ищите обращения к /xmlrpc.php. Важно не просто увидеть факт запросов, а понять их источник и частоту. Один запрос от Jetpack и тысячи попыток с разных IP — это разные сценарии.

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

Если доступа к логам нет, можно временно добавить небольшой фильтр в WordPress и записывать обращения в error log. Это не замена логам сервера, но для короткой проверки подходит.

<?php
add_action('init', function () {
    if (isset($_SERVER['REQUEST_URI']) && strpos($_SERVER['REQUEST_URI'], 'xmlrpc.php') !== false) {
        error_log('XML-RPC request from ' . ($_SERVER['REMOTE_ADDR'] ?? 'unknown'));
    }
});

Такой код лучше ставить во временный mu-plugin, а не в тему. После проверки его нужно удалить.

Пошаговое решение: как закрыть XML-RPC

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

Способ	Где работает	Плюсы	Минусы
.htaccess / Nginx	до загрузки WordPress	не тратит PHP, режет запрос рано	нужно аккуратно настроить сервер
PHP-фильтр	внутри WordPress	просто внедрить, удобно для теста	запрос уже дошёл до PHP
Комбинированный	сервер + WordPress	максимально жёстко	можно случайно сломать интеграции

Вариант 1: блокировка через .htaccess на Apache

Если сайт работает на Apache, можно запретить доступ к файлу xmlrpc.php напрямую. Это не зависит от темы и плагинов, поэтому подходит для большинства установок.

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

Если у вас старый Apache 2.2, синтаксис будет другим, но на актуальных версиях используется именно Require all denied. После правки проверьте, что файл действительно отдаёт 403, а не 500.

Вариант 2: блокировка в Nginx

На Nginx удобнее закрыть отдельный location. Это тоже режет запрос до PHP и обычно предпочтительнее, если у вас есть доступ к конфигу сервера.

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

После изменения конфигурации не забудьте проверить её и перезагрузить Nginx. Иначе правило просто не применится.

nginx -t
systemctl reload nginx

Вариант 3: отключение через PHP-фильтр

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

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter('xmlrpc_enabled', '__return_false');

Этот вариант удобен тем, что его легко откатить. Но он не защищает от лишних обращений на уровне веб-сервера, поэтому при атаке лучше не ограничиваться только им.

Как не сломать Jetpack и мобильные приложения

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

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

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

После блокировки нужно убедиться не только в том, что файл недоступен, но и в том, что сайт не потерял нужные интеграции. Проверка занимает несколько минут и экономит часы на разборе жалоб.

• откройте /xmlrpc.php в браузере или через curl;
• убедитесь, что сервер возвращает 403 Forbidden или другой ожидаемый отказ;
• проверьте вход через обычную форму WordPress;
• если используете Jetpack, проверьте подключение и синхронизацию;
• посмотрите логи сервера: новых ошибок PHP быть не должно.

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

Если вы видите 200 OK, блокировка не сработала. Если видите 500, значит, проблема в конфигурации, а не в самой идее отключения.

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

Ставят запрет не туда

Частая ошибка — добавляют правило в файл, который не читается сервером, или правят конфиг Nginx, но сайт работает на Apache. Сначала определите стек, потом меняйте конфигурацию.

Путают отключение XML-RPC с защитой от brute force

Даже если XML-RPC закрыт, это не отменяет защиту формы входа, лимиты на попытки авторизации и нормальную работу 2FA. XML-RPC — только один из каналов атаки.

Ломают рабочую интеграцию и не замечают сразу

Иногда сайт продолжает открываться, но перестаёт публиковать записи через внешний сервис или теряет связь с Jetpack. Поэтому проверка должна быть функциональной, а не только по HTTP-коду.

Оставляют временный код в теме

Если вы использовали PHP-решение для теста, не держите его в functions.php надолго. Лучше вынести в mu-plugin или удалить после внедрения серверного правила.

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

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

Если у вас несколько сайтов на одном сервере, проверьте, не используется ли один и тот же шаблон конфигурации для всех. Ошибка в общем include может закрыть XML-RPC там, где он ещё нужен. Лучше вносить изменение точечно и фиксировать его в конфигурации проекта.

Для сайтов, где важна минимизация дублей и технического мусора, полезно параллельно проверить другие лишние точки входа: /wp-json/, старые endpoint’ы плагинов, неиспользуемые формы авторизации и открытые тестовые каталоги. Если нужен более широкий аудит технических дублей и лишних страниц, в экосистеме WPShop есть Clearfy Pro: https://wpshop.ru/plugins/clearfy.

Главная идея простая: сначала выясняете, кто использует XML-RPC, потом закрываете его на правильном уровне и только после этого проверяете рабочие сценарии. Такой порядок снижает риск поломок и не оставляет сайт с ложным ощущением защищённости.