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

Автор: Людмила Данилова | Опубликовано: 07.09.2026

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

Ниже — рабочая схема: сначала понять, нужен ли вам этот интерфейс вообще, затем выбрать способ блокировки и проверить, что сайт после этого ведёт себя нормально.

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

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

Типичный сценарий выглядит так:

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

Что важно проверить до изменений

Перед блокировкой откройте список подключённых сервисов и вспомните, не используется ли что-то из этого:

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

Если есть сомнения, сначала проверьте логи и интеграции, а уже потом режьте доступ.

Какой способ блокировки выбрать: сервер или PHP

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

Способ	Где работает	Плюс	Минус
.htaccess / nginx	На уровне веб-сервера	Не нагружает WordPress	Нужно править конфиг сервера
PHP-хук	Внутри WordPress	Проще внедрить в теме или плагине	Запрос уже дошёл до WordPress

Если у вас Apache или LiteSpeed с поддержкой .htaccess, можно закрыть доступ там. Если nginx — правило добавляют в конфиг сервера. Если доступа к серверу нет, используйте PHP-вариант через мини-плагин или functions.php, но лучше не вносить это в активную тему, если тема может меняться.

Блокировка XML-RPC через .htaccess

Для Apache/LiteSpeed самый прямой вариант — запретить доступ к xmlrpc.php на уровне веб-сервера. Это не отключает сам файл физически, но делает его недоступным извне.

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

Этот блок можно добавить в корень сайта в .htaccess, рядом с правилами WordPress. Если у вас старый синтаксис Apache 2.2, иногда встречается вариант:

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

Но если сервер современный, лучше использовать Require all denied. Он понятнее и соответствует актуальной конфигурации Apache.

Если у вас nginx

В nginx правило выглядит иначе и пишется в конфиг сайта:

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

После правки конфигурации не забудьте проверить её синтаксис и перезагрузить nginx. Иначе можно получить не защиту, а простой сайта.

Блокировка через PHP в WordPress

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

<?php
add_filter( 'xmlrpc_enabled', '__return_false' );

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

Мини-плагин для отключения XML-RPC

Если хотите сделать это аккуратно, создайте файл, например disable-xmlrpc.php в каталоге wp-content/plugins/:

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

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

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

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

Что искать в логах:

частые POST-запросы к xmlrpc.php;
повторяющиеся попытки авторизации с одного IP;
подозрительные запросы с методом system.multicall;
ошибки 401, 403 или 405 на этом файле.

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

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

Для Apache путь к логу может отличаться, но логика та же: сначала убедиться, что endpoint не нужен, потом отключать.

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

Проверьте, используются ли Jetpack, старые мобильные приложения или внешние публикационные сервисы.
Посмотрите логи и убедитесь, что xmlrpc.php не нужен для рабочих сценариев.
Выберите способ блокировки: серверный вариант предпочтительнее.
Внесите правило в .htaccess или nginx-конфиг, либо добавьте фильтр xmlrpc_enabled через мини-плагин.
Очистите кэш, если он есть на сайте, на сервере или в CDN.
Проверьте ответ на запрос к /xmlrpc.php и убедитесь, что обычная работа сайта не изменилась.

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

Проверка должна быть не формальной, а практической. Откройте /xmlrpc.php в браузере или отправьте запрос через curl. В зависимости от способа блокировки вы должны увидеть отказ в доступе или отключённый endpoint.

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

Если блокировка на уровне сервера работает, обычно будет 403 Forbidden. Если вы отключали XML-RPC через WordPress, ответ может отличаться, но главное — endpoint не должен принимать рабочие запросы на авторизацию и публикацию.

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

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

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

Отключили XML-RPC, а потом перестал работать Jetpack

Значит, сервис действительно использовал этот канал. В таком случае нужно либо вернуть доступ, либо перевести интеграцию на другой способ подключения, если он поддерживается вашим сценарием. Не стоит закрывать endpoint вслепую, если интеграция уже завязана на него.

Добавили правило в .htaccess, но ничего не изменилось

Чаще всего причина в том, что сайт работает не на Apache/LiteSpeed, а на nginx, либо правило добавили не в тот файл. Ещё один вариант — конфиг перезаписывается панелью хостинга. В этом случае проверяйте, где именно хостинг хранит правила сайта.

После правки появилась ошибка 500

Обычно это синтаксическая ошибка в конфиге. Для .htaccess достаточно лишнего символа или неверной директивы, чтобы сайт упал. Возвращайте файл к предыдущей версии и вносите изменения заново, по одному блоку.

Отключили XML-RPC через functions.php и потеряли изменение после обновления темы

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

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

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

Ограничьте попытки входа в админку, если на сайте идут атаки на авторизацию.
Проверьте, не торчит ли наружу лишний функционал в плагинах и теме.
Следите за логами после изменения: иногда атаки просто переключаются на другой путь.
Если нужен более широкий технический аудит, удобно сначала убрать дубли и мусорные настройки, а уже потом точечно закрывать endpoints. Для этого часто используют Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpturbo.ru&utm_medium=article&utm_campaign=otklyuchit-xmlrpc-v-wordpress-cherez-htaccess-i-php

Главная идея простая: не отключайте XML-RPC только потому, что это «модно». Сначала проверьте, нужен ли он вашему сайту, потом выберите способ блокировки и обязательно убедитесь, что рабочие сценарии не сломались.

⭐⭐⭐⭐⭐