Как отключить XML-RPC в WordPress без поломки сайта

Автор: Полина Ширяева | Опубликовано: 17.08.2026

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

Когда XML-RPC становится проблемой

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

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

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

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

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

Быстрая проверка с помощью curl

Можно вручную проверить, отвечает ли endpoint:

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

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

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

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

Если ничего из этого нет, отключение обычно безопасно. Если что-то есть, лучше сначала заменить интеграцию или протестировать на staging-копии.

Как отключить XML-RPC: рабочие варианты

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

Способ	Плюсы	Минусы	Когда выбирать
Код в теме или mu-plugin	Прозрачно, легко контролировать	Нужно не забыть про обновления темы	Если у вас есть доступ к коду
Правило на сервере	Срабатывает раньше WordPress	Нужен доступ к конфигу веб-сервера	Если нужно отрезать запросы до PHP
Плагин безопасности	Быстро включить без кода	Лишняя зависимость от плагина	Если сайт ведётся без разработки

Вариант 1: отключить XML-RPC через код

Самый понятный способ — добавить фильтр xmlrpc_enabled. Лучше делать это не в functions.php активной темы, а в небольшом mu-plugin, чтобы настройка не исчезла после смены темы.

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

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

Вариант 2: заблокировать доступ на уровне сервера

Если задача — именно отрезать внешний доступ к файлу, можно сделать это на уровне веб-сервера. Для Apache подойдёт правило в .htaccess:

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

Для Nginx логика задаётся в конфигурации сайта. Типовой вариант выглядит так:

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

Этот способ полезен, если к сайту идёт заметный мусорный трафик и вы хотите отсечь его до запуска PHP. Но если у вас shared-хостинг без доступа к конфигу, этот вариант может быть недоступен.

Вариант 3: использовать плагин безопасности

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

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

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

Проверьте логи и убедитесь, что xmlrpc.php действительно атакуют или вызывают без необходимости.
Составьте список сервисов, которые могут зависеть от XML-RPC.
Если есть сомнения, протестируйте отключение на staging-сайте.
Выберите способ: код, сервер или плагин.
После внедрения проверьте, что xmlrpc.php больше не отвечает или возвращает отказ.
Убедитесь, что редактор, админка и внешние интеграции работают как раньше.

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

Проверка должна быть не формальной, а практической. Откройте https://example.com/xmlrpc.php в браузере или выполните запрос через curl. Если вы отключали XML-RPC через WordPress-фильтр, файл может по-прежнему открываться, но WordPress будет возвращать отказ в обработке. Если блокировка сделана на сервере, запрос должен завершаться ошибкой доступа.

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

Что считать успешным результатом:

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

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

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

Отключили XML-RPC, а потом перестал работать нужный сервис

Такое бывает, если заранее не проверили зависимости. Решение простое: верните доступ, найдите конкретную интеграцию и переведите её на REST API или другой способ подключения. Не отключайте XML-RPC «на всякий случай», если у вас есть внешние клиенты публикации.

Добавили правило в .htaccess, но оно не сработало

Причина часто в том, что сайт работает не на Apache, а на Nginx, либо .htaccess вообще не обрабатывается. В этом случае нужно править конфиг веб-сервера или использовать код WordPress.

Поставили плагин безопасности, но нагрузка не упала

Некоторые плагины не блокируют запросы на уровне сервера, а только отключают обработку внутри WordPress. Это полезно, но не всегда достаточно, если атака идёт массово. Тогда лучше перенести блокировку в Nginx/Apache или ограничить доступ через WAF.

Отключили XML-RPC, но не проверили логи

Иногда кажется, что всё работает, но запросы продолжают приходить и нагружать сервер. После изменений обязательно смотрите access log: если обращения не исчезли, значит блокировка стоит не там, где нужно.

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

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

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

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