XML-RPC в WordPress часто отключают из соображений безопасности: через него идут старые сценарии публикации, удалённые вызовы и часть атак на вход. Но в реальных проектах проблема почти всегда упирается в другое: на сайте уже подключён Jetpack, мобильное приложение WordPress или внешний сервис, который всё ещё ходит через xmlrpc.php. Если просто закрыть файл на уровне сервера, можно получить отвал синхронизации, публикации и статистики.
Ниже разберём, как отключать XML-RPC точечно: сначала понять, кто именно его использует, затем закрыть лишнее и не сломать нужное. Подход подойдёт для обычного WordPress-сайта без WooCommerce-специфики.
Когда XML-RPC действительно стоит отключать
Если сайт не использует удалённую публикацию, старые мобильные клиенты и интеграции, XML-RPC обычно не нужен. На практике его оставляют включённым только ради нескольких сценариев:
- Jetpack и связанные с ним функции синхронизации;
- мобильное приложение WordPress;
- внешние клиенты для публикации по XML-RPC;
- редкие сервисы, которые до сих пор не перешли на REST API.
Если ничего из этого не используется, отключение XML-RPC уменьшает поверхность атаки. Но делать это лучше после проверки, а не «на всякий случай».
Диагностика: кто обращается к xmlrpc.php
Первый шаг — понять, есть ли реальные обращения к /xmlrpc.php. Если на сайте стоят логи веб-сервера, посмотрите их за последние дни. В Nginx это обычно access.log, в Apache — аналогичный access log.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если логов нет под рукой, можно проверить хотя бы косвенные признаки:
- Jetpack пишет об ошибке соединения или синхронизации;
- мобильное приложение WordPress не публикует записи;
- внешний сервис сообщает о
403,405или ошибке авторизации; - в панели безопасности видны попытки брутфорса через
xmlrpc.php.
Важно отличать «кто-то стучится извне» от «это реально нужно сайту». Если запросы идут только от ботов, отключение безопасно. Если в логах есть IP Jetpack или вашего сервиса публикации, сначала проверьте совместимость.
Что выбрать: плагин, код или серверное правило
Есть три рабочих способа. Они не равнозначны: один удобен, другой надёжнее, третий проще откатить.
| Способ | Когда подходит | Плюсы | Минусы |
|---|---|---|---|
| Плагин безопасности | Нужен быстрый переключатель без правок кода | Просто включить и выключить, часто есть журнал | Лишняя зависимость, иногда закрывает XML-RPC слишком грубо |
| Код в теме или mu-plugin | Нужно точечное управление | Контроль поведения, можно оставить исключения | Нужно следить за обновлениями и местом размещения кода |
| Правило на сервере | Нужно жёстко закрыть доступ | Запрос даже не доходит до WordPress | Можно случайно сломать нужную интеграцию |
Если у вас есть Jetpack или мобильное приложение, обычно лучше начать с кода: так проще оставить сайт доступным для нужных вызовов и быстро откатить изменения.
Пошаговое решение: отключаем XML-RPC без лишних поломок
Шаг 1. Проверьте, нужен ли XML-RPC Jetpack
Если Jetpack используется только для статистики или части модулей, он не всегда требует полного доступа к XML-RPC. Но если у вас включена синхронизация, публикация или удалённые функции, отключение может вызвать ошибки. Самый надёжный путь — сначала временно выключить правило блокировки и проверить, исчезнут ли предупреждения в Jetpack.
Если сайт не использует Jetpack, этот шаг можно пропустить.
Шаг 2. Добавьте фильтр для отключения XML-RPC
Самый аккуратный способ — через functions.php дочерней темы или, лучше, через mu-plugin. Так код не потеряется при обновлении темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант полностью отключает XML-RPC на уровне WordPress. Если вам не нужны исключения, этого достаточно.
Если нужно оставить доступ только для части сценариев, можно не отключать всё целиком, а блокировать конкретные методы. Но это уже более тонкая настройка и требует понимания, какие именно вызовы используются. Для большинства сайтов это избыточно.
Шаг 3. Закройте прямой доступ на уровне сервера, если XML-RPC не нужен вообще
Если вы уверены, что 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. Но если у вас остался рабочий клиент, он тоже перестанет подключаться. Поэтому сначала проверьте логи и зависимости.
Шаг 4. Если нужен только Jetpack, проверьте альтернативу
В некоторых случаях Jetpack можно перевести на работу без старых сценариев, но это зависит от конкретных модулей и версии. Не стоит рассчитывать, что любое отключение XML-RPC пройдёт незаметно. После изменения конфигурации откройте настройки Jetpack и убедитесь, что соединение не разорвано.
Как проверить, что решение сработало
Проверка должна быть не формальной, а практической. Смотрите не только код ответа, но и реальные функции сайта.
- Откройте
https://ваш-домен/xmlrpc.phpв браузере: если доступ закрыт, вы не должны видеть рабочий ответ XML-RPC. - Проверьте логи сервера: новые обращения к
xmlrpc.phpдолжны получать отказ или не доходить до WordPress. - Если используется Jetpack, проверьте его статус в админке WordPress.
- Если используется мобильное приложение WordPress, попробуйте создать черновик или обновить запись.
- Если есть внешний сервис публикации, выполните тестовое подключение.
Для быстрой проверки кода ответа можно использовать curl:
curl -I https://example.com/xmlrpc.phpЕсли вы закрывали файл на уровне сервера, ожидаемое поведение — 403 Forbidden или другой отказ, в зависимости от конфигурации. Если отключали только фильтром WordPress, сервер может отдавать страницу, но сам XML-RPC будет неактивен.
Частые ошибки и как их исправить
Сразу закрыли xmlrpc.php на сервере и сломали Jetpack
Это самая частая ошибка. Сначала проверьте, есть ли реальные зависимости. Если Jetpack нужен, не начинайте с жёсткого deny. Сначала отключите XML-RPC через фильтр и протестируйте поведение плагина.
Добавили код в родительскую тему
После обновления темы код исчезает, и XML-RPC снова включается. Для таких правок используйте дочернюю тему или mu-plugin. Это особенно важно, если вы ведёте сайт не один и не хотите ловить «магические» откаты после апдейта.
Поставили плагин безопасности и забыли, что он уже блокирует XML-RPC
Иногда админ видит, что xmlrpc.php недоступен, и добавляет ещё одно правило в .htaccess или Nginx. В результате диагностика становится путаной: непонятно, что именно блокирует доступ. Если используете плагин, сначала проверьте его настройки, а потом уже правьте сервер.
Отключили XML-RPC, но не проверили внешние интеграции
Сайт может выглядеть нормально, но публикация из мобильного приложения или синхронизация с сервисом заметно сломается позже. После изменений обязательно сделайте тестовый сценарий: публикация, обновление записи, вход через приложение, работа Jetpack.
Практические советы по безопасности и производительности
Если цель — не просто убрать старый интерфейс, а реально снизить риск, полезно сочетать несколько мер:
- отключайте XML-RPC только после проверки логов;
- не держите одновременно несколько способов блокировки, если не понимаете, какой из них сработает первым;
- если XML-RPC не нужен, закройте его на сервере, а не только в WordPress;
- не используйте сомнительные «security-plugins» с непонятной логикой блокировок;
- после изменений проверьте кэш, если у вас стоит серверный или плагинный кэш, чтобы не смотреть на старую страницу состояния.
Если вам нужно регулярно чистить сайт от лишних технических сущностей, дублирующихся архивов и мусорных страниц, имеет смысл держать под рукой инструменты для технической оптимизации. Например, Clearfy Pro от WPShop может помочь с частью SEO- и cleanup-задач, но XML-RPC всё равно лучше контролировать отдельно, а не полагаться на один плагин для всего.
Когда лучше не отключать XML-RPC полностью
Полное отключение не всегда оправдано. Если сайт активно редактируют через мобильное приложение, если есть старый, но рабочий сервис публикации, или если Jetpack завязан на XML-RPC в вашей конфигурации, лучше оставить доступ и ограничить его другими способами: сложными паролями, ограничением логина, WAF, rate limiting и проверкой логов.
В таких случаях задача не «убрать XML-RPC любой ценой», а сократить риск без потери рабочих сценариев. Это обычно и есть правильный компромисс для живого проекта.