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

Автор: София Фролова | Опубликовано: 17.09.2026

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

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

Когда XML-RPC можно отключать, а когда нельзя

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

Что обычно ломается первым

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

Если у вас в логах есть запросы к /xmlrpc.php, это ещё не значит, что endpoint нужен. Но это уже повод посмотреть, кто именно его вызывает.

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

Начните с логов веб-сервера. На nginx это обычно access log, на Apache — аналогичный access log. Ищите обращения к /xmlrpc.php. Если запросы идут регулярно и от известных сервисов, отключать endpoint без замены нельзя.

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

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

Полезно также проверить, не включён ли Jetpack и не завязан ли он на XML-RPC в вашей конфигурации. Если Jetpack нужен, не отключайте endpoint до теста на staging-копии.

Способы отключения: сравнение вариантов

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

Способ	Плюсы	Минусы
Плагин безопасности	Быстро, без правок кода	Дополнительная нагрузка, лишняя зависимость
Код в теме или mu-plugin	Контролируемо, без лишнего UI	Нужно не забыть про обновления и перенос
nginx/Apache	Режет запросы раньше WordPress	Требует доступа к серверу и аккуратной настройки

Для продакшена чаще всего удобнее код в mu-plugin или правило на сервере. Плагин имеет смысл, если вам нужен быстрый переключатель без доступа к конфигам.

Пошаговое решение через код

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

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

Этот вариант отключает сам XML-RPC на уровне WordPress. Если кто-то попытается обратиться к /xmlrpc.php, WordPress не будет обрабатывать запрос как обычно.

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

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

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

Пошаговое решение через nginx или Apache

Если у вас есть доступ к серверу, лучше заблокировать запросы к xmlrpc.php на уровне веб-сервера. Тогда WordPress даже не будет получать лишние запросы.

nginx

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

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

Apache

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

Правило можно добавить в .htaccess или в конфиг виртуального хоста, если у вас такой доступ есть. Для shared-хостинга чаще доступен только .htaccess.

Как не сломать Jetpack и внешние клиенты

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

Откройте Jetpack и проверьте, нет ли ошибок подключения.
Попробуйте опубликовать запись через мобильное приложение WordPress, если вы им пользуетесь.
Проверьте сторонние сервисы автопостинга или синхронизации.
Посмотрите логи на 404/403 по /xmlrpc.php и сопоставьте с источниками запросов.

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

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

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

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

Ожидаемое поведение зависит от способа блокировки. При серверном deny это может быть 403 Forbidden. При отключении через WordPress — ответ может отличаться, но главное, чтобы endpoint не выполнял XML-RPC-методы.

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

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

Отключили XML-RPC в теме

Это плохая идея: при смене темы настройка пропадёт. Перенесите код в mu-plugin или отдельный плагин.

Сразу заблокировали endpoint на сервере без проверки

Так часто ломают Jetpack и старые клиенты. Сначала проверьте логи и реальные сценарии использования, потом режьте доступ.

Оставили XML-RPC включённым, но убрали только pingback

Это не полноценная защита. Если цель — снизить риск атак, лучше отключить endpoint полностью.

Проверили только в браузере

/xmlrpc.php не тестируют глазами. Нужен запрос через curl и проверка логов после изменения.

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

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

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

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

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