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

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

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

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

Быстрая диагностика: кто вообще обращается к xmlrpc.php

Начните с логов веб-сервера. Если у вас Nginx, ищите запросы к /xmlrpc.php и смотрите IP, User-Agent и частоту. На Apache логика та же: важны повторяющиеся обращения, особенно с одинаковыми параметрами и без успешной авторизации. Если доступа к логам нет, можно временно включить запись в access.log на уровне хостинга или проверить статистику в панели.

Полезно также проверить сам сайт на наличие зависимостей:

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

Если вы не уверены, лучше сначала ограничить доступ, а не удалять поддержку полностью.

Как отключить XML-RPC: сравнение подходов

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

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

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

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

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

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

Если сайт работает на Nginx, можно отдать 403 для xmlrpc.php. Это хороший вариант, когда вы уверены, что endpoint не нужен вообще.

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

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

Вариант 3: использовать плагин только для блокировки

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

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

Ниже рабочая последовательность, которая помогает не сломать интеграции.

1. Проверьте логи и список подключённых сервисов.
2. Сделайте резервную копию конфигурации и файлов.
3. Сначала отключите XML-RPC в тестовой среде или на staging.
4. Проверьте вход через приложение, Jetpack и внешние публикации.
5. Если всё работает без XML-RPC, перенесите блокировку на продакшен.
6. После внедрения ещё раз проверьте ответы /xmlrpc.php и ошибки в логах.

Если у вас есть доступ к WP-CLI, полезно хотя бы проверить, какие плагины активны и не завязаны ли они на удалённую публикацию. Сам XML-RPC через WP-CLI не отключается, но диагностика окружения становится проще.

wp plugin list --status=active
wp option get active_plugins

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

Проверка должна быть не «страница открывается», а именно «endpoint больше не принимает запросы». Самый простой тест — отправить запрос на xmlrpc.php и посмотреть код ответа.

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

Ожидаемый результат зависит от способа блокировки:

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

Дополнительно проверьте:

• вход через мобильное приложение WordPress;
• работу Jetpack, если он установлен;
• автопостинг и внешние интеграции;
• ошибки в error.log и access.log после блокировки.

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

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

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

Сделали deny all в Nginx, но WordPress всё равно отвечает

Чаще всего правило не попало в активный server block, либо его перекрывает другое location-правило. Проверьте порядок директив и убедитесь, что конфиг действительно загружен. После правки всегда делайте nginx -t и только потом reload.

Отключили через тему, а после обновления всё вернулось

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

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

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

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

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

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

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