Как отключить XML-RPC на уровне .htaccess и проверить, что сайт не ломается

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

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

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

Типичные признаки, что XML-RPC можно закрывать

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

Если хотя бы один пункт вызывает сомнение, сначала проверьте зависимости. Иначе можно получить не «усиление безопасности», а поломку интеграции, которую потом сложно диагностировать по симптомам.

Диагностика: как понять, используется ли XML-RPC сейчас

Самый надёжный способ — не гадать, а проверить фактические обращения. Сначала посмотрите access log сервера. Если там есть регулярные POST-запросы к /xmlrpc.php, это уже повод выяснить источник. Дальше проверьте, нет ли у вас плагинов или внешних сервисов, которые используют удалённую публикацию.

Что проверить перед отключением

• логи Nginx или Apache за последние 7–14 дней;
• настройки Jetpack, если он установлен;
• мобильные приложения, которые могут публиковать записи;
• интеграции с внешними редакторами и автопостингом;
• наличие старых плагинов для удалённого управления сайтом.

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

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

Открытый endpoint обычно отвечает кодом 405 или 200 с текстом об ошибке метода, а не 404. Это нормально для стандартной установки WordPress. Но если вы хотите закрыть его на уровне сервера, дальше нужно сделать это так, чтобы запросы не доходили до PHP.

Как отключить XML-RPC через .htaccess

Для сайтов на Apache или LiteSpeed самый прямой вариант — правило в .htaccess. Оно блокирует доступ к xmlrpc.php до обработки WordPress. Это лучше, чем просто ставить фильтр в functions.php, потому что запрос не расходует ресурсы PHP и не попадает в логи приложения как обычный вызов.

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

Если сервер старый и использует Apache 2.2, синтаксис будет другим:

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

Правило лучше размещать выше стандартного блока WordPress, чтобы оно сработало раньше. После правки не забудьте очистить кеш, если перед сайтом стоит плагин кеширования или CDN.

Когда лучше не использовать .htaccess

Если сайт работает на Nginx, .htaccess не поможет — сервер его просто не читает. В этом случае блокировку нужно делать в конфигурации виртуального хоста. Для Nginx это обычно выглядит так:

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

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

Сравнение подходов: плагин, код, сервер

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

Пошаговое решение без лишнего риска

Ниже рабочая последовательность, которая помогает не сломать сайт на ровном месте.

1. Проверьте, используется ли XML-RPC внешними сервисами.
2. Сделайте резервную копию .htaccess или конфигурации Nginx.
3. Добавьте правило блокировки на уровне сервера.
4. Очистите кеш сайта и CDN.
5. Проверьте ответ /xmlrpc.php и логи после изменения.

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

add_filter( 'xmlrpc_enabled', '__return_false' );

Такой код можно добавить в мини-плагин или в functions.php дочерней темы. Но если цель — именно убрать лишнюю нагрузку и закрыть точку входа, потом всё равно лучше перенести блокировку на уровень веб-сервера.

Как проверить, что отключение сработало

Проверка должна быть не «страница открылась», а именно по endpoint XML-RPC. Самый простой тест — запрос к xmlrpc.php после внесения изменений. Если блокировка настроена правильно, сервер должен вернуть 403 Forbidden или 404, в зависимости от конфигурации.

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

Дополнительно проверьте:

• в логах больше нет успешных обращений к /xmlrpc.php;
• админка WordPress работает как обычно;
• публикация записей из браузера не изменилась;
• если есть Jetpack или внешняя интеграция, она не потеряла связь;
• нет ошибок 500 после правки .htaccess или конфигурации Nginx.

Если после блокировки сайт начал отдавать 500, почти всегда проблема в синтаксисе правила. Для Apache это обычно лишний символ или неверное место вставки. Для Nginx — правило добавили не в тот server блок или забыли перезагрузить конфигурацию.

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

Блокируют XML-RPC в WordPress, но не на сервере

Это рабочий, но слабый вариант. Запрос всё равно доходит до PHP, а значит, ресурс тратится зря. Если на сайт идёт много мусорных обращений, лучше закрыть endpoint раньше — в .htaccess или Nginx.

Ломают Jetpack или внешнюю публикацию

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

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

Это разные вещи. Отключение XML-RPC не выключает REST API WordPress. Если у вас есть отдельная задача по закрытию REST для неавторизованных пользователей, это решается отдельно и не заменяет блокировку xmlrpc.php.

Не проверяют кеш и CDN

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

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

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

На нагруженных сайтах серверная блокировка даёт ещё и небольшой выигрыш по ресурсам: запросы не доходят до WordPress, не запускают загрузку ядра и не пишут лишние записи в PHP-логи. Это не «ускорение сайта» в маркетинговом смысле, а просто устранение ненужной работы.

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

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