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

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

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

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

Сначала проверьте, используется ли он вообще. Сам по себе факт наличия файла xmlrpc.php в корне WordPress не означает проблему. Проблема начинается, когда endpoint открыт и при этом не нужен ни одному рабочему процессу.

Типичные сценарии, где отключение оправдано

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

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

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

Самый практичный способ — посмотреть логи доступа и проверить, есть ли реальные обращения к xmlrpc.php не от ботов. Если у вас есть доступ к access.log, ищите строку с этим путём и анализируйте user-agent и IP.

grep 'xmlrpc.php' /var/log/nginx/access.log | tail -n 50

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

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

Если ничего из этого не используется, отключение обычно безопасно.

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

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

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

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

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

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

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

Вариант 2: закрыть xmlrpc.php на уровне Nginx

Если у вас Nginx, можно отдать 403 для xmlrpc.php. Это полезно, когда вы хотите убрать запросы ещё до загрузки WordPress.

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

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

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

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

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

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

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

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

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

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

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

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

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

не ломается ли вход через мобильное приложение WordPress;
не перестал ли работать Jetpack;
нет ли ошибок в access.log и error.log;
не появляются ли повторные попытки доступа к xmlrpc.php с вашего же сервера или CDN.

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

Отключили XML-RPC, а потом сломали интеграцию

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

Добавили правило в тему, а потом сменили шаблон

Если код лежит в functions.php активной темы, при смене темы защита исчезнет. Для технических ограничений лучше использовать mu-plugin или отдельный мини-плагин.

Закрыли endpoint на сервере, но WordPress всё равно отвечает

Так бывает, если правило не попало в нужный server block или VirtualHost. Проверьте, что конфигурация применяется именно к нужному домену, и после правок перезагрузите веб-сервер.

Поставили плагин, но он конфликтует с кэшем или безопасностью

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

Что ещё стоит проверить вместе с XML-RPC

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

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

Здесь важно не превращать hardening в набор случайных запретов. Любое ограничение должно быть связано с конкретной задачей: убрать ненужный доступ, сократить поверхность атаки или уменьшить технический шум.

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

Если вы отключаете XML-RPC ради безопасности, не забудьте про базовые вещи, которые реально дают эффект: обновления ядра и плагинов, ограничение админ-доступа, 2FA для редакторов, нормальные пароли и WAF на уровне хостинга или CDN. XML-RPC — только один из входов, а не вся безопасность сайта.

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

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

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