XML-RPC в WordPress до сих пор включён на многих сайтах по умолчанию, хотя в реальных проектах он часто не нужен. Проблема в том, что его отключают «в лоб», а потом ломают сторонние сервисы: мобильные приложения, внешние публикации, интеграции с Jetpack или старые клиенты. Если задача — убрать лишнюю точку атаки и снизить шум от брутфорса, отключать XML-RPC можно, но только после проверки, что он действительно нигде не используется.
Когда XML-RPC лучше отключить, а когда оставить
XML-RPC нужен не всем. Если вы не публикуете записи через внешние приложения, не используете старые интеграции и не завязаны на сервисы, которые ходят в /xmlrpc.php, его можно убрать без потери функциональности. На типичном сайте это уменьшает поверхность атаки и убирает один из популярных векторов перебора логинов.
Оставлять XML-RPC имеет смысл, если:
- вы используете Jetpack и конкретные функции, которым нужен XML-RPC;
- публикуете контент из внешних клиентов или мобильных приложений, которые работают через XML-RPC;
- у вас есть старые интеграции, которые нельзя быстро перевести на REST API.
Если сомневаетесь, сначала проверьте логи доступа и список подключённых сервисов. Отключение без диагностики — частая причина «внезапно перестал работать редактор в приложении».
Диагностика: используется ли xmlrpc.php на вашем сайте
Самый практичный способ — посмотреть, есть ли реальные обращения к /xmlrpc.php в логах веб-сервера. Если запросы идут только от сканеров и ботов, отключение обычно безопасно. Если есть регулярные вызовы от известных IP или сервисов, сначала разберитесь, кто именно их делает.
Что проверить перед изменениями
- логи Nginx/Apache на обращения к
/xmlrpc.php; - настройки Jetpack и других плагинов, которые могут использовать XML-RPC;
- внешние приложения для публикации и синхронизации;
- нет ли в проекте старых скриптов, которые отправляют XML-RPC-запросы.
Если доступа к логам нет, можно временно заблокировать XML-RPC на тестовом стенде и посмотреть, что перестанет работать. На боевом сайте так делать без проверки не стоит.
Пошаговое решение: как отключить XML-RPC безопасно
Есть три рабочих подхода: через код, через сервер и через плагин безопасности. Для контроля и предсказуемости чаще всего удобнее код или серверная настройка. Плагин подходит, если вы уже используете его для других задач и хотите управлять всем из админки.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Понятно, прозрачно, легко откатить | Нужно не забыть про обновления темы |
| Правило на сервере | Блокирует запросы раньше PHP | Нужен доступ к конфигу Nginx/Apache |
| Плагин безопасности | Быстро включить без кода | Добавляет зависимость от плагина |
Вариант 1: отключить XML-RPC через код
Самый аккуратный способ — добавить фильтр в mu-plugin или в небольшой плагин сайта. Так вы не потеряете настройку при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter('xmlrpc_enabled', '__return_false');Если нужен более жёсткий вариант, можно сразу отдавать 403 на сам файл xmlrpc.php. Это полезно, когда вы хотите не просто отключить функциональность, а полностью закрыть endpoint.
<?php
/**
* Plugin Name: Block XML-RPC Requests
*/
add_action('init', function () {
if (defined('XMLRPC_REQUEST') && XMLRPC_REQUEST) {
status_header(403);
exit;
}
});На практике первый вариант чаще достаточно надёжен. Второй имеет смысл, если вы хотите явно блокировать запросы даже при нестандартной обработке.
Вариант 2: закрыть xmlrpc.php на сервере
Если у вас Nginx, можно отдать 403 на прямой доступ к файлу. Это снижает нагрузку и не даёт запросу доходить до WordPress.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правило в .htaccess или конфиге виртуального хоста:
<Files xmlrpc.php>
Require all denied
</Files>Серверный способ хорош тем, что он не зависит от состояния WordPress. Но если вы позже забудете, что блокировка стоит именно на сервере, можно долго искать причину неработающей интеграции.
Вариант 3: отключение через плагин безопасности
Если у вас уже стоит плагин, который умеет управлять XML-RPC, используйте его только как часть общей политики безопасности. Это удобно, когда нужно быстро включить защиту без правок файлов. Но не стоит ставить отдельный плагин только ради одной галочки, если ту же задачу решает код.
Проверка результата после внедрения
После отключения важно убедиться, что вы действительно закрыли endpoint и ничего лишнего не сломали. Проверка занимает пару минут, но экономит время на разбор инцидентов.
- Откройте
/xmlrpc.phpв браузере или черезcurlи проверьте ответ сервера. - Убедитесь, что в логах больше нет успешных обращений к этому файлу.
- Проверьте, работают ли редактор, REST API и обычная авторизация в админке.
- Если есть Jetpack или внешние сервисы, протестируйте их отдельно.
Пример проверки через curl:
curl -I https://example.com/xmlrpc.phpЕсли всё сделано правильно, вы увидите 403 Forbidden или другой ожидаемый отказ в доступе. Если приходит 200 OK, блокировка не сработала или перекрыта другим правилом.
Частые ошибки и как их исправить
Отключили XML-RPC в теме, а потом сменили тему
Если фильтр лежит в functions.php, он исчезнет при смене темы. Для таких настроек лучше использовать mu-plugin или отдельный мини-плагин сайта.
Заблокировали не тот endpoint
Иногда путают xmlrpc.php и REST API. Это разные механизмы. Если после правок перестали работать мобильные приложения или интеграции, проверьте, не задели ли вы /wp-json/ правилами на сервере.
Сломали Jetpack или публикацию из внешнего клиента
Если сервис действительно использует XML-RPC, его нужно либо перевести на другой способ интеграции, либо оставить endpoint включённым и закрыть его дополнительной защитой: ограничением по IP, WAF или более строгой аутентификацией.
Поставили плагин и забыли про конфликты
Некоторые security-плагины дублируют друг друга по функциям. Если один плагин уже блокирует XML-RPC, второй может только усложнить диагностику. Лучше держать одну точку управления и понимать, где именно включено правило.
Практические советы по безопасности и производительности
Отключение XML-RPC — не замена нормальной защите входа в админку. Если сайт регулярно атакуют, стоит дополнительно проверить:
- ограничение попыток входа;
- 2FA для администраторов;
- актуальность ядра, тем и плагинов;
- наличие WAF или хотя бы базовых правил на уровне сервера;
- отсутствие лишних открытых endpoint'ов.
Если вы ведёте сайт на стандартном стеке и параллельно чистите дубли, технический мусор и лишние индексы, имеет смысл смотреть и на сопутствующие настройки. Например, в Clearfy Pro есть инструменты для отключения неиспользуемых функций WordPress и снижения лишнего шума в коде сайта: https://wpshop.ru/plugins/clearfy.
Главное правило простое: сначала проверьте зависимости, потом блокируйте endpoint, затем подтвердите результат через логи и curl. Тогда отключение XML-RPC останется точечной мерой, а не причиной аварии на сайте.