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

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

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

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

Отключение имеет смысл, если:

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

Что может сломаться

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

Диагностика: нужен ли вам XML-RPC вообще

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

Быстрая проверка по логам

На nginx это обычно выглядит как поиск по access log:

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

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

Проверка через сам сайт

Откройте https://ваш-домен/xmlrpc.php. Если файл доступен, WordPress обычно отвечает сообщением о том, что XML-RPC server accepts POST requests only. Это не ошибка само по себе, но подтверждает, что endpoint открыт. Если вы уже закрыли его на уровне сервера или плагина, ответ может быть 403 или 404 — это нормально, если так и планировалось.

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

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

Способ	Плюсы	Минусы	Когда выбирать
Плагин	Быстро, без правок конфигов	Дополнительный плагин, иногда избыточно	Если нет доступа к серверу
Код в теме/му-плагине	Контролируемо, без лишних зависимостей	Нужно аккуратно разместить код	Если есть доступ к файлам сайта
nginx/Apache	Режет запросы до WordPress	Нужен доступ к конфигу	Если важна защита и производительность

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

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

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

Это простой и понятный вариант. Но он отключает XML-RPC на уровне WordPress, а значит запрос всё равно дойдёт до PHP. Для небольших сайтов это обычно не критично, но с точки зрения производительности серверный блок лучше.

Вариант 2: закрыть на уровне nginx

Если сайт работает на nginx, можно сразу отдавать 403 на запросы к xmlrpc.php:

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

Такой вариант не даёт WordPress вообще обрабатывать запрос. Это полезно, если вы хотите снизить шум в логах и отрезать лишний трафик раньше, чем он попадёт в PHP.

Вариант 3: закрыть через Apache

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

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

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

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

Проверьте, используются ли Jetpack, мобильные приложения WordPress или внешние сервисы публикации.
Посмотрите логи на обращения к /xmlrpc.php и оцените, это рабочий трафик или атаки.
Выберите способ отключения: код, сервер или плагин.
Сделайте изменение сначала на staging, если он есть.
После внедрения проверьте доступ к endpoint и работоспособность зависимых сервисов.

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

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

Проверка должна быть не только «страница не открывается», но и «ничего нужного не сломалось». Сначала откройте /xmlrpc.php в браузере или через curl. Затем проверьте, что ваши рабочие сценарии остались живыми.

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

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

После этого проверьте:

авторизацию в Jetpack, если он используется;
публикацию из мобильного приложения WordPress;
интеграции, которые отправляют записи на сайт;
логи сервера — обращений к xmlrpc.php должно стать меньше или они должны получать отказ.

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

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

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

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

Некоторые плагины блокируют XML-RPC на уровне WordPress, но не режут запросы на сервере. В логах вы всё равно будете видеть обращения, а PHP будет тратить ресурсы на обработку. Если цель — защита и снижение нагрузки, лучше закрывать endpoint на nginx или Apache.

Сломали доступ из-за правки в основной теме

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

Закрыли endpoint, но забыли проверить внешние сервисы

Самая неприятная ошибка — отключить XML-RPC и узнать об этом через неделю, когда перестала работать публикация из стороннего инструмента. Поэтому всегда сначала смотрите зависимости, а уже потом режьте доступ.

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

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

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

Если вам нужен не только контроль XML-RPC, но и общая чистка сайта от лишнего технического мусора, посмотрите в сторону инструментов, которые умеют отключать ненужные функции WordPress и упрощать техобслуживание. Например, у Clearfy Pro есть набор настроек для технической оптимизации и удаления лишнего функционала: https://wpshop.ru/plugins/clearfy.

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