Как отключить xmlrpc.php в WordPress и не сломать нужные интеграции

Автор: Тимур Федоров | Опубликовано: 12.08.2026

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

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

Когда xmlrpc.php действительно стоит отключать

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

Быстрый чек перед изменениями

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

Диагностика: как понять, что проблема именно в xmlrpc.php

Если сайт получает много подозрительных запросов, в логах веб-сервера часто видно обращения к /xmlrpc.php. Это не всегда атака, но если запросы идут пачками и с разными логинами, причина понятна. Ещё один признак — в панели безопасности или в логах хостинга видно много 200/403/404 по этому пути.

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

Пошаговое решение: как отключить xmlrpc.php

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

Способ	Где применять	Плюсы	Минусы
Блокировка на сервере	Nginx/Apache	Режет запрос до WordPress, меньше нагрузки	Нужен доступ к конфигу
Правило в .htaccess	Apache	Быстро внедряется без плагинов	Не работает на Nginx
Фильтр WordPress	Тема/мини-плагин	Не требует доступа к серверу	Запрос уже доходит до WordPress

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

Если сайт работает на Apache, добавьте правило в .htaccess выше стандартного блока WordPress. Это самый простой способ для shared-хостинга.

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

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

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

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

Для Nginx правило добавляют в конфиг сайта. Это предпочтительнее, потому что запросы не доходят до PHP-FPM и не расходуют ресурсы WordPress.

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

После правки не забудьте проверить конфиг и перезагрузить Nginx. Типичная последовательность выглядит так:

nginx -t
systemctl reload nginx

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

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

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

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

Если XML-RPC нужен частично: как не сломать Jetpack и интеграции

Иногда полностью отключать XML-RPC нельзя. Например, Jetpack может использовать его для части функций. В таком случае не стоит ставить грубую блокировку вслепую. Сначала проверьте, действительно ли конкретный модуль зависит от XML-RPC, и только потом принимайте решение.

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

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

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

Что проверить вручную

Откройте /xmlrpc.php в браузере или через curl.
Убедитесь, что сервер возвращает 403 Forbidden или другой ожидаемый отказ.
Проверьте, не появились ли ошибки в логах WordPress, PHP и веб-сервера.
Если используется Jetpack или внешний клиент, протестируйте их отдельно.

Простой запрос через curl покажет, что путь не отдаёт содержимое:

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

Ожидаемый результат — отказ в доступе, а не обычный ответ WordPress. Если вы видите 200 OK, блокировка не сработала или применяется не на том уровне.

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

Удалили файл xmlrpc.php вручную

Так делать не стоит. Файл может быть восстановлен при обновлении, а ручное удаление усложняет диагностику. Блокируйте доступ, а не ломайте структуру ядра.

Добавили правило не в тот блок конфигурации

На Nginx правило должно попадать в нужный server-блок. Если его добавить в общий конфиг или в неправильный виртуальный хост, запросы продолжат проходить.

Сломали Jetpack и не поняли почему

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

Использовали плагин, который делает слишком много

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

Практика безопасности: что ещё сделать вместе с отключением

Отключение XML-RPC — не замена нормальной защите админки. Если атаки идут на логин, имеет смысл добавить ограничение попыток входа, двухфакторную аутентификацию и проверку прав пользователей. Если у вас есть доступ к серверу, полезно ещё и ограничить частоту запросов к /wp-login.php и /xmlrpc.php на уровне веб-сервера или CDN.

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

Как понять, что решение действительно сработало

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

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