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

Автор: Маргарита Ширяева | Опубликовано: 19.09.2026

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

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

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

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

Диагностика: кто вообще обращается к xmlrpc.php

Перед изменениями посмотрите, есть ли реальные запросы к /xmlrpc.php. Если у вас есть доступ к логам веб-сервера, это самый надёжный способ. Ищите не только частоту, но и источник запросов.

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

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

в админке установлен Jetpack и он активен;
используются внешние приложения для публикации;
есть интеграции с сервисами, которые отправляют записи по XML-RPC;
в логах безопасности видно много запросов к xmlrpc.php с разных IP.

Если вы не уверены, лучше сначала ограничить доступ, а не удалять поддержку полностью.

Пошаговое решение: как отключить XML-RPC безопасно

Вариант 1. Блокировка на уровне WordPress

Если нужен быстрый и обратимый способ, можно отключить XML-RPC через фильтр. Добавьте код в functions.php дочерней темы или в небольшой mu-plugin.

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

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

Вариант 2. Блокировка на уровне веб-сервера

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

Для Nginx:

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

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

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

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

Вариант 3. Ограничить, а не отключать

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

Подход	Что делает	Плюс	Минус
Фильтр `xmlrpc_enabled`	Отключает функциональность в WordPress	Просто откатить	Файл всё ещё доступен веб-серверу
Блокировка на сервере	Отсекает запросы до PHP	Снижает нагрузку	Можно сломать внешние интеграции
Ограничение по IP	Разрешает доступ только доверенным адресам	Гибко для закрытых сервисов	Нужно поддерживать список IP

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

После внесения изменений проверьте не только сам URL, но и связанные сценарии.

Откройте /xmlrpc.php в браузере или через curl — ожидаем либо отказ, либо пустой ответ без полезной функциональности.
Проверьте Jetpack, если он установлен: авторизация и синхронизация должны работать так, как вы планировали.
Посмотрите логи сервера через 10–15 минут: количество запросов к xmlrpc.php должно упасть или перестать доходить до PHP.
Если используете внешние публикации, попробуйте тестовую отправку записи.

Пример проверки через curl:

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

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

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

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

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

Добавили правило в .htaccess, но оно не сработало

На Apache правило может быть перебито другими директивами или вообще не применяться, если сайт работает на Nginx. Сначала определите стек сервера, а потом вносите изменения в правильный слой.

Отключили через плагин безопасности и забыли, где именно

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

Проверили только главную страницу и решили, что всё в порядке

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

Безопасность и производительность: что ещё имеет смысл сделать

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

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

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

Когда лучше не отключать XML-RPC полностью

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

Практически правильный порядок такой: сначала диагностика, затем ограничение доступа, потом — полное отключение, если после проверки ничего не сломалось.