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

Автор: Анна Мельникова | Опубликовано: 21.08.2026

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

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

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

Что обычно ломается после отключения

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

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

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

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

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

Для более точной проверки можно отправить тестовый запрос и посмотреть ответ. Если XML-RPC включен, WordPress обычно отвечает не 404, а осмысленной ошибкой или сообщением о методе:

curl -s -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>' https://example.com/xmlrpc.php

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

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

Выбор зависит от того, насколько жестко нужно закрыть доступ и есть ли у вас доступ к серверной конфигурации. Ниже — варианты от самого аккуратного к более жесткому.

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

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

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

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

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

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

Если сайт работает на Nginx, можно запретить доступ к файлу напрямую. Это полезно, когда вы хотите отрезать запросы еще до запуска WordPress:

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

После изменения конфига проверьте, что сайт не использует XML-RPC через интеграции. Если что-то сломалось, откатите правило и ищите конкретный сервис, который зависит от этого endpoint.

Вариант 3: блокировка в .htaccess для Apache

На Apache можно закрыть файл через .htaccess. Это удобно, если у вас нет доступа к основному конфигу виртуального хоста:

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

Если сервер старый и использует Apache 2.2, синтаксис может отличаться, но на современных установках обычно нужен именно Require all denied.

Пошаговое решение без сюрпризов

Проверьте логи на обращения к /xmlrpc.php.
Убедитесь, что не используете Jetpack, мобильное приложение WordPress и сторонние клиенты публикации через XML-RPC.
Выберите способ блокировки: код, сервер или плагин.
Внедрите изменение сначала на тестовой копии сайта.
После публикации проверьте, что endpoint отвечает 403 или не доступен.
Протестируйте все интеграции, которые могли использовать XML-RPC.

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

Проверка должна быть не только «страница открывается». Нужны конкретные признаки:

https://example.com/xmlrpc.php больше не отвечает как рабочий endpoint;
в логах нет успешных POST запросов к XML-RPC;
мобильное приложение и интеграции, если они есть, не зависят от этого канала;
в панели безопасности или логах сервера исчезли повторяющиеся попытки обращения к файлу.

Минимальный тест через curl выглядит так:

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

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

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

Отключили XML-RPC, а Jetpack перестал синхронизироваться

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

Поставили плагин, но запросы все равно идут

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

Закрыли файл, но забыли про тестовый и staging-домен

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

Смешали отключение XML-RPC с отключением REST API

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

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

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

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

Если вам нужен именно жесткий контроль, лучше разделять уровни: WordPress-фильтр для логики, веб-сервер для блокировки, логи для проверки. Такой подход проще сопровождать и легче откатывать, чем набор разрозненных правок в теме.