XML-RPC в WordPress часто отключают по одной причине: через него проще атаковать сайт перебором паролей и отправкой лишних запросов. Но у этого механизма есть и легитимные сценарии — старые мобильные клиенты, внешние сервисы публикации, некоторые интеграции и пинги. Поэтому правильный вопрос не «как выключить всё подряд», а «что именно у меня использует XML-RPC и можно ли заменить это REST API или обычной авторизацией».
Если на сайте нет внешних подключений, отключение XML-RPC обычно не вызывает проблем. Если же вы не уверены, сначала проверьте, не используются ли endpoint /xmlrpc.php и методы вроде pingback.ping или metaWeblog.newPost. Ниже — рабочие способы отключения, проверка результата и типичные ошибки, из-за которых сайт потом «вдруг» перестаёт публиковать записи из внешнего редактора.
Когда XML-RPC действительно стоит отключать
На практике отключение оправдано, если сайт не использует:
- старые приложения для публикации постов;
- удалённые сервисы, которым нужен XML-RPC, а не REST API;
- pingback и trackback через XML-RPC;
- интеграции, завязанные на классический WordPress API.
Если сайт живёт только в админке и через обычный фронтенд, XML-RPC чаще всего не нужен. Для безопасности это полезная точка сокращения поверхности атаки. Но если вы используете Jetpack, внешние мобильные клиенты или старые интеграции, сначала проверьте их документацию: часть сценариев уже давно работает через другие механизмы.
Диагностика: как понять, используется ли XML-RPC сейчас
Самый простой тест — открыть /xmlrpc.php в браузере или через curl. Сам по себе файл может отвечать даже при частичной блокировке, поэтому важнее смотреть на поведение метода и логи. Если endpoint доступен, это ещё не значит, что он реально нужен.
Проверка через curl
curl -i https://example.com/xmlrpc.phpОжидаемое поведение зависит от конфигурации. Если XML-RPC отключён корректно, вы можете увидеть 403, 404 или кастомный ответ от сервера/плагина безопасности. Если endpoint отвечает стандартно, значит он доступен извне.
Что смотреть в логах
- частые POST-запросы к
/xmlrpc.php; - ошибки авторизации с разных IP;
- попытки вызова методов
system.multicallиpingback.ping; - неожиданные ошибки у внешних сервисов после блокировки.
Если у вас есть доступ к access log, это лучший источник. По нему видно, кто и как часто обращается к endpoint. Если логов нет, ориентируйтесь на функциональные симптомы: перестали публиковаться записи из внешнего клиента, пропали пингбеки, сломалась синхронизация с сервисом.
Как отключить XML-RPC: код, плагин или сервер
Есть три нормальных подхода. Выбор зависит от того, где вам удобнее поддерживать правило и нужно ли оставить исключения.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Код в теме или mu-plugin | Нужен контроль и предсказуемость | Без лишних зависимостей, легко проверить | Нужно не забыть про обновления темы |
| Плагин безопасности | Нужна настройка без кода | Быстро включить, часто есть дополнительные фильтры | Лишний плагин, возможны пересечения с другими правилами |
| Блокировка на сервере | Нужно отсечь запросы до WordPress | Меньше нагрузки, защита раньше PHP | Требует доступа к конфигу сервера |
Вариант 1: отключить через код
Если нужен прозрачный и проверяемый способ, добавьте фильтр в functions.php дочерней темы или, лучше, в отдельный mu-plugin. Для большинства сайтов этого достаточно.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. Если кто-то обратится к /xmlrpc.php, WordPress не будет обрабатывать запрос как обычно. Для сайта это самый понятный способ, если вы хотите сохранить контроль в коде.
Вариант 2: заблокировать доступ к xmlrpc.php на сервере
Если у вас Apache, можно закрыть файл на уровне веб-сервера. Это полезно, когда вы хотите отрезать запросы ещё до загрузки WordPress.
<Files xmlrpc.php>
Require all denied
</Files>Для Nginx логика другая: правило добавляют в конфигурацию сайта. Конкретный синтаксис зависит от вашей схемы, но смысл один — вернуть 403 на запрос к /xmlrpc.php. Это снижает лишнюю нагрузку и не даёт PHP вообще стартовать для таких запросов.
Вариант 3: использовать плагин
Если код трогать не хочется, можно использовать плагин безопасности или оптимизации, который умеет отключать XML-RPC. Например, в Clearfy Pro есть набор настроек для технической чистки сайта и отключения лишних функций. Это удобно, когда вы уже централизуете такие правила в одном месте.
Но здесь важно не дублировать логику: если XML-RPC уже заблокирован сервером, дополнительный плагин не нужен. Сначала выберите один уровень контроля, потом проверьте, не конфликтует ли он с другими правилами безопасности.
Пошаговое решение без лишнего риска
- Проверьте, используется ли XML-RPC внешними сервисами и клиентами.
- Выберите один способ блокировки: код, сервер или плагин.
- Внесите изменение в тестовой среде или в окно низкой нагрузки.
- Проверьте доступ к
/xmlrpc.phpи работу критичных интеграций. - Посмотрите логи на предмет ошибок авторизации и неожиданных 403.
Если вы работаете с продакшеном, не меняйте сразу всё: сначала отключите XML-RPC на одном сайте или в staging, затем проверьте публикацию, вход в админку, работу внешних сервисов и только после этого переносите правило на боевой сайт.
Как проверить, что отключение сработало
Проверка должна быть не только визуальной. Откройте https://example.com/xmlrpc.php и посмотрите код ответа. Если вы блокировали на уровне WordPress, ответ может быть 403 или другой отказ в зависимости от плагина/сервера. Если блокировка через код не сработала, endpoint будет отвечать как обычно.
Дополнительно проверьте, что:
- внешний клиент публикации больше не может отправить запись;
- в логах нет повторяющихся POST к
/xmlrpc.php; - не появляются ошибки у сервисов, которые вы действительно используете;
- админка и REST API работают как раньше.
Если у вас есть мониторинг, добавьте отдельную проверку на ответ /xmlrpc.php. Это полезно, потому что после обновлений плагинов или миграций правило иногда теряется.
Частые ошибки и как их исправить
Отключили XML-RPC, а сломался Jetpack или внешний редактор
Значит, сервис всё ещё использовал XML-RPC, а не REST API. Решение — либо вернуть доступ точечно, либо перевести интеграцию на поддерживаемый способ подключения. Не оставляйте правило «как есть», если оно ломает рабочий сценарий.
Добавили код в активную тему и забыли про обновление
После смены темы правило исчезнет. Для таких задач лучше использовать mu-plugin или отдельный мини-плагин. Это особенно важно, если сайт обслуживает не один разработчик.
Поставили плагин безопасности и серверную блокировку одновременно
В итоге сложно понять, что именно даёт 403 и где искать проблему. Если нужно отлаживать интеграцию, временно оставьте один уровень защиты. Иначе вы будете ловить «ложные» ошибки и тратить время на диагностику.
Закрыли endpoint, но не посмотрели логи
Если на сайт идёт много запросов к /xmlrpc.php, их лучше увидеть и оценить. Иногда это просто шум ботов, а иногда — реальный внешний сервис, о котором забыли. Без логов легко принять неверное решение.
Практика безопасности и производительности
Отключение XML-RPC не делает сайт «защищённым полностью», но убирает один из популярных векторов атак. Это особенно полезно вместе с ограничением попыток входа, нормальной политикой паролей и обновлениями ядра, тем и плагинов.
С точки зрения производительности выгода не в магическом ускорении, а в том, что сервер перестаёт тратить ресурсы на бессмысленные запросы. Если боты часто стучатся в /xmlrpc.php, блокировка на уровне веб-сервера обычно эффективнее, чем обработка в PHP.
Если вы уже используете набор технической чистки и хотите централизовать отключение лишних функций, имеет смысл держать такие настройки в одном месте, а не размазывать их по нескольким плагинам и файлам темы. Это проще сопровождать и легче проверять после обновлений.
В итоге рабочая схема обычно такая: сначала диагностика, потом один способ блокировки, затем проверка логов и тест внешних интеграций. Если XML-RPC не нужен, его лучше отключить осознанно, а не наугад.