XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестаёт работать мобильное приложение, внешняя публикация или старый сервис автопостинга. На практике задача не в том, чтобы просто закрыть xmlrpc.php, а в том, чтобы сначала понять, кто его использует, и только потом выбрать способ блокировки.
Если сайт не использует внешние клиенты, XML-RPC обычно можно отключить. Но если у вас есть Jetpack, мобильное приложение WordPress, интеграции через старые API-клиенты или сервисы публикации, сначала нужна диагностика. Иначе получите не «усиление безопасности», а поломку рабочих сценариев.
Когда XML-RPC действительно стоит отключать
Самая частая причина — лишняя поверхность атаки. Через xmlrpc.php часто пытаются подбирать логины и пароли, а также нагружать сайт множественными запросами. Если вы не используете удалённую публикацию и не подключаете внешние клиенты, этот интерфейс обычно не нужен.
Но есть и обратная сторона: XML-RPC всё ещё нужен некоторым легаси-интеграциям. Поэтому решение должно опираться не на общую рекомендацию из статьи, а на проверку конкретного сайта.
Что проверить перед отключением
- используется ли мобильное приложение WordPress;
- подключён ли Jetpack и какие его модули активны;
- есть ли внешние сервисы публикации или автопостинга;
- есть ли старые интеграции, которые отправляют запросы в
xmlrpc.php; - не завязаны ли на XML-RPC какие-то внутренние скрипты или cron-задачи.
Диагностика: как понять, кто обращается к xmlrpc.php
Начните с логов веб-сервера. Если в access log регулярно видны запросы к /xmlrpc.php, это уже повод посмотреть, откуда они идут и что именно вызывают. Важно не путать обычные обращения поисковых роботов с попытками брутфорса: у XML-RPC обычно характерны частые POST-запросы.
Если доступа к логам нет, можно временно поставить простую проверку на уровне WordPress и фиксировать обращения в error log. Это не замена нормальному мониторингу, но для короткой диагностики подходит.
<?php
add_action('init', function () {
if (isset($_SERVER['REQUEST_URI']) && strpos($_SERVER['REQUEST_URI'], 'xmlrpc.php') !== false) {
error_log('XML-RPC request from ' . ($_SERVER['REMOTE_ADDR'] ?? 'unknown'));
}
});Такой код не нужно держать постоянно. Он нужен только чтобы понять, есть ли реальные обращения и можно ли отключать интерфейс без последствий.
Как отключить XML-RPC: три рабочих варианта
Выбор зависит от того, где вам удобнее блокировать запрос: на уровне WordPress, на уровне плагина безопасности или на уровне веб-сервера. С точки зрения надёжности лучше блокировать как можно раньше, но не всегда это удобно в хостинге с ограниченным доступом.
| Способ | Плюсы | Минусы |
|---|---|---|
| Код в теме или mu-plugin | Контроль без лишних плагинов | Нужно следить за обновлениями и местом подключения |
| Плагин безопасности | Быстро включить, не трогая код | Дополнительная зависимость, не всегда точная блокировка |
| Блокировка на сервере | Режет запрос до загрузки WordPress | Требует доступа к конфигу nginx/apache |
Вариант 1: отключить XML-RPC через код
Если нужен прозрачный и предсказуемый способ, добавьте фильтр xmlrpc_enabled. Это штатный механизм WordPress, без выдуманных хуков и обходных трюков.
<?php
add_filter('xmlrpc_enabled', '__return_false');Лучше размещать такой код в mu-plugins или в небольшом собственном плагине, а не в functions.php активной темы. Тогда отключение не исчезнет при смене темы.
Вариант 2: закрыть xmlrpc.php на уровне nginx или Apache
Если у вас есть доступ к конфигу веб-сервера, это самый жёсткий и экономный по ресурсам вариант. Запросы будут отрезаны до запуска WordPress.
Для nginx можно использовать отдельное правило:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Для Apache обычно используют правила в .htaccess:
<Files xmlrpc.php>
Require all denied
</Files>Если сайт работает через управляемый хостинг, сначала проверьте, не конфликтует ли такое правило с их внутренними механизмами. На некоторых платформах доступ к конфигу ограничен, и тогда проще использовать код или плагин.
Вариант 3: плагин безопасности
Если вам нужно быстро закрыть XML-RPC без правок кода, подойдёт плагин безопасности, который умеет отключать этот интерфейс. Но здесь важно смотреть не на название функции в интерфейсе, а на то, как плагин реализует блокировку: через фильтр WordPress, через rewrite или через серверные правила.
Если в проекте уже есть плагин для чистки и SEO-оптимизации, например Clearfy Pro, проверьте, не дублирует ли он эту настройку с другими мерами безопасности. Дублирование само по себе не критично, но лишние переключатели потом мешают понять, что именно сработало.
Пошаговая схема внедрения без риска
- Проверьте логи и убедитесь, что через
xmlrpc.phpне идут нужные интеграции. - Сделайте резервную копию файлов и базы.
- Выберите один основной способ блокировки: код, сервер или плагин.
- Внедрите изменение сначала на тестовой копии сайта, если она есть.
- После включения проверьте ответ
xmlrpc.phpи рабочие сценарии.
Если вы отключаете XML-RPC кодом, лучше не смешивать это с другими экспериментами в той же итерации. Иначе будет сложно понять, что именно сломало интеграцию, если что-то пойдёт не так.
Как проверить, что отключение сработало
Самый простой тест — открыть /xmlrpc.php в браузере или через curl. В норме после отключения вы не должны получать стандартный ответ WordPress для XML-RPC.
curl -I https://example.com/xmlrpc.phpЕсли блокировка сделана на уровне сервера, часто будет 403 Forbidden. Если через фильтр WordPress — ответ может отличаться в зависимости от конфигурации, но сам XML-RPC должен перестать принимать запросы.
Дополнительно проверьте реальные сценарии:
- вход через мобильное приложение WordPress;
- публикацию из внешнего клиента;
- работу Jetpack, если он используется;
- отсутствие ошибок в логах после отключения.
Если что-то перестало работать, не возвращайте XML-RPC целиком «на всякий случай». Сначала найдите конкретную интеграцию и решите, можно ли заменить её REST API или другим способом доступа.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про Jetpack
Jetpack в некоторых конфигурациях использует XML-RPC для связи с WordPress.com. Если после блокировки пропали отдельные функции плагина, проверьте его документацию и текущие модули. Иногда проблема не в самом Jetpack, а в том, что вы отключили канал, через который он синхронизируется.
Поставили несколько способов блокировки сразу
Когда XML-RPC отключён и в плагине, и в .htaccess, и ещё фильтром в коде, диагностика становится мутной. Для эксплуатации это не всегда плохо, но для отладки — лишняя сложность. Сначала оставьте один способ, потом при необходимости добавляйте второй как резервный.
Сломали мобильное приложение и не заметили сразу
Если редакторы работают через приложение WordPress, отключение XML-RPC может проявиться не сразу. Поэтому после внедрения обязательно проверьте не только главную страницу, но и реальные пользовательские сценарии публикации и редактирования.
Сделали блокировку только в WordPress
Фильтр xmlrpc_enabled отключает функциональность на уровне CMS, но запрос всё равно доходит до WordPress. Если сайт часто атакуют, серверная блокировка эффективнее: она снижает лишнюю нагрузку и сокращает шум в логах.
Что делать, если XML-RPC нужен частично
Иногда отключать его полностью нельзя. Например, нужен только один внешний сервис или старый рабочий процесс. В таком случае лучше не держать интерфейс открытым для всех, а ограничить сам сценарий доступа: сменить интеграцию на REST API, использовать отдельный сервисный аккаунт, пересмотреть права пользователя и убрать лишние функции.
Если задача именно в безопасности, а не в полном отказе от удалённой публикации, подумайте о минимизации поверхности: сильные пароли, ограничение попыток входа, двухфакторная аутентификация, актуальные обновления ядра и плагинов. XML-RPC — только один из каналов, а не единственная точка риска.
Практика для производительности и безопасности
На нагруженных сайтах блокировка XML-RPC помогает не только с безопасностью, но и с шумом в логах и лишними запросами. Это не «ускорение в разы», а нормальная гигиена: меньше мусорных обращений, проще анализировать реальные проблемы, меньше ложных срабатываний в мониторинге.
Если у вас уже есть набор технических оптимизаций, удобно держать такие настройки в одном месте — в собственном mu-plugin или в плагине для системных правок. Тогда отключение XML-RPC не потеряется после обновления темы и не будет зависеть от ручных правок в админке.
Перед выкладкой на боевой сайт проверьте ещё раз: нет ли внешних клиентов, не используются ли старые интеграции, и действительно ли ответ xmlrpc.php закрыт. Это тот случай, когда короткая диагностика экономит больше времени, чем последующий откат.