Как отключить XML-RPC в WordPress без поломки синхронизации и отладить блокировки

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

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

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

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

Типичный признак лишней активности — большое количество запросов к /xmlrpc.php в логах веб-сервера или в security-плагине. Часто это не «атака на сайт», а обычный брутфорс по известной точке входа. В таком случае отключение или ограничение доступа имеет смысл, но только после проверки зависимостей.

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

Начните не с кода, а с наблюдения. Посмотрите access log и найдите обращения к xmlrpc.php. Если запросы идут регулярно, важно понять, это ваш сервис или чужой сканер.

Что проверить в первую очередь

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

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

<?php
/**
 * Plugin Name: XML-RPC request logger
 */

add_action('xmlrpc_call', function ($method) {
    error_log('XML-RPC method: ' . $method);
});

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

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

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

Вариант 1. Отключить XML-RPC через фильтр

Самый простой способ — вернуть false через фильтр xmlrpc_enabled. Это штатный механизм WordPress, без выдуманных хуков и без лишней магии.

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

Код можно добавить в functions.php дочерней темы, но практичнее вынести в небольшой mu-plugin, чтобы он не зависел от темы.

Вариант 2. Заблокировать доступ на уровне сервера

Если цель — снизить нагрузку и отсечь запросы ещё до WordPress, блокируйте xmlrpc.php в конфигурации веб-сервера. Это полезно, когда сайт регулярно получает мусорный трафик.

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

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

Для Nginx логика обычно выносится в конфиг виртуального хоста:

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

Если у вас управляемый хостинг, сначала проверьте, не перезаписывает ли панель свои правила при обновлении конфигурации.

Вариант 3. Оставить XML-RPC, но ограничить риск

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

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

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

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

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

Простой тест через командную строку:

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

Если блокировка настроена корректно, вы увидите отказ в доступе на уровне сервера или пустой ответ без обработки WordPress. Если же страница всё ещё отдаёт стандартный ответ WordPress, значит правило не сработало или перекрывается другим конфигом.

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

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

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

Добавили код в тему, а после обновления он пропал

Если фильтр xmlrpc_enabled лежит в functions.php активной темы, обновление или смена темы может его убрать. Для технических ограничений лучше использовать mu-plugin: он не зависит от темы и загружается стабильно.

Заблокировали файл на сервере, но WordPress всё равно отвечает

Чаще всего правило не попало в нужный блок конфигурации или было переопределено другим location/директивой. Проверьте порядок правил и перезагрузите конфигурацию веб-сервера. На Apache также важно убедиться, что .htaccess вообще читается.

Сломали внешнюю интеграцию и не поняли какую

Это происходит, когда XML-RPC отключают без предварительной диагностики. Чтобы не гадать, временно включите логирование методов или посмотрите access log за последние дни. Если внешняя система критична, лучше заменить её на REST API или другой официальный канал интеграции.

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

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

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

Короткий чек-лист перед отключением

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

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