Как отключить XML-RPC в WordPress и не сломать Jetpack, мобильные приложения и внешние сервисы

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

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

Когда XML-RPC действительно мешает

Проблема обычно проявляется не в админке, а на уровне логов и сетевых запросов. Типичные признаки: много обращений к /xmlrpc.php, попытки подбора паролей, нагрузка от внешних скриптов, а также ошибки в интеграциях, которые раньше работали через удалённый доступ к WordPress.

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

Сначала ответьте на три вопроса:

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

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

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

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

На сервере можно быстро отследить обращения по логам веб-сервера. Например, для Nginx:

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

Если логов нет под рукой, проверьте сам endpoint из браузера или через curl. Нормально, если он отвечает не как обычная страница сайта, а как служебный PHP-эндпоинт WordPress.

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

Для более точной проверки можно временно включить логирование на уровне сервера или использовать плагин безопасности, который показывает частоту обращений к этому файлу. Но не путайте частые запросы с реальной полезной нагрузкой: иногда это просто сканирование со стороны ботов.

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

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

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

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

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

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

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

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

Если задача — не просто выключить функциональность, а ещё и снизить лишнюю нагрузку, блокируйте доступ к xmlrpc.php на веб-сервере. Это особенно полезно, если сайт регулярно сканируют.

Для Nginx:

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

Для Apache можно использовать правило в .htaccess:

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

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

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

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

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

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

1. Проверьте, используется ли XML-RPC в реальных сценариях сайта.
2. Сделайте резервную копию файлов и базы перед изменениями.
3. Выберите способ отключения: код, сервер или плагин.
4. Внесите изменение сначала на staging, если он есть.
5. Проверьте, не сломались ли Jetpack, мобильные клиенты и внешние сервисы.
6. Посмотрите логи на предмет 403/404 и повторных попыток доступа.

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

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

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

• Откройте /xmlrpc.php в браузере или через curl и проверьте, что ответ изменился на отказ в доступе или что WordPress больше не обрабатывает запрос.
• Посмотрите access log: обращения к xmlrpc.php должны либо исчезнуть, либо получать 403.
• Проверьте Jetpack, если он установлен, и убедитесь, что нужные модули не зависят от XML-RPC в вашем сценарии.
• Если используете внешнюю публикацию, попробуйте отправить тестовый пост из того сервиса, который был подключён раньше.

Для быстрой проверки через консоль можно использовать:

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

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

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

Отключили XML-RPC, а потом перестал работать Jetpack

Значит, вы не проверили зависимости заранее. Верните доступ и посмотрите, какие функции Jetpack реально используются. Иногда достаточно заменить сценарий синхронизации или отказаться только от части модулей, а не от всего протокола.

Поставили плагин, но endpoint всё равно отвечает

Некоторые плагины отключают только обработку в WordPress, но не блокируют сам файл на уровне сервера. Если нужен жёсткий запрет, добавьте правило в Nginx или Apache.

Сломались внешние интеграции, о которых никто не знал

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

После блокировки выросло число 403 в логах

Это не всегда проблема. Часто это просто боты, которые продолжают сканировать endpoint. Но если 403 идут от ваших же сервисов, значит, нужно искать источник запроса и перенастраивать интеграцию.

Что ещё стоит сделать для безопасности

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

Практически полезный минимум:

• ограничить попытки входа в админку;
• использовать сложные пароли и уникальные учётные записи;
• обновлять ядро, темы и плагины без задержек;
• проверять, не открыт ли xmlrpc.php после обновления плагинов безопасности или смены конфигурации сервера.

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

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