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

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

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

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

Что обычно ломается после отключения

Чаще всего проблемы проявляются не сразу. Сайт продолжает открываться, но перестают работать отдельные сценарии:

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

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

Диагностика: используется ли xmlrpc.php на вашем сайте

Начните с простого аудита. Посмотрите логи веб-сервера, если они доступны, и проверьте, есть ли обращения к /xmlrpc.php. Если запросы идут регулярно и не похожи на атаку, значит, кто-то или что-то реально использует этот endpoint.

Быстрая проверка через браузер и curl

Откройте https://ваш-домен/xmlrpc.php. Если XML-RPC включён, WordPress обычно отвечает сообщением о том, что сервер принимает только POST-запросы. Это не доказывает наличие зависимости, но подтверждает, что endpoint доступен.

Для более точной проверки можно отправить тестовый POST-запрос:

curl -i -X POST https://example.com/xmlrpc.php

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

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

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

Как отключить XML-RPC безопасно

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

Вариант через код WordPress

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

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

Лучше размещать такой код не в теме, а в небольшом mu-plugin, чтобы он не исчез при смене темы. Например, создайте файл wp-content/mu-plugins/disable-xmlrpc.php:

<?php
/**
 * Plugin Name: Disable XML-RPC
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

Это решение отключает сам механизм WordPress, но не мешает веб-серверу принимать запросы на xmlrpc.php. Для большинства сайтов этого достаточно.

Вариант через nginx

Если у вас nginx, можно отрезать доступ к файлу на уровне сервера. Это полезно, когда нужно не просто выключить функцию, а сразу прекратить обработку запросов.

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

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

Если нужен не полный запрет, а ограничение

Иногда XML-RPC нужен только для одного сервиса. Тогда вместо полного отключения можно ограничить доступ по IP на уровне сервера или закрыть endpoint через WAF. Это сложнее в сопровождении, зато не ломает нужную интеграцию.

Пошаговое решение: отключаем и не теряем рабочие сценарии

1. Составьте список внешних сервисов, которые могут обращаться к сайту.
2. Проверьте логи xmlrpc.php за последние дни или недели.
3. Убедитесь, что никто из команды не публикует через мобильное приложение WordPress.
4. Выберите способ отключения: код, сервер или плагин.
5. Внесите изменение сначала на тестовой копии сайта, если она есть.
6. После внедрения проверьте админку, публикацию записей и работу интеграций.

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

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

Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере и отправьте тестовый POST-запрос. Если XML-RPC отключён через фильтр WordPress, endpoint не должен выполнять методы XML-RPC. Если блокировка сделана на сервере, запрос должен завершаться отказом доступа.

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

• нет ли ошибок в логах после отключения;
• работает ли обычная авторизация в админке;
• публикуются ли записи вручную;
• не пропали ли уведомления от внешних сервисов;
• не выросло ли число 403/401 на других endpoint’ах из-за слишком широкого правила.

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

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

Отключили XML-RPC, не проверив мобильное приложение

Если кто-то из редакторов публикует через приложение WordPress, оно может перестать синхронизироваться. Решение простое: либо вернуть XML-RPC, либо перевести команду на работу через браузер и заранее предупредить о смене процесса.

Поставили два разных ограничения одновременно

Например, плагин безопасности уже блокирует xmlrpc.php, а вы добавили ещё и правило nginx. В итоге диагностика становится мутной: непонятно, где именно сработал запрет. Лучше сначала оставить один механизм и только потом добавлять второй, если есть реальная необходимость.

Сломали интеграцию, но не нашли, какая именно использовала XML-RPC

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

Использовали код в теме

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

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

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

• ограничение попыток входа;
• актуальность ядра, тем и плагинов;
• наличие двухфакторной аутентификации для админов;
• правила WAF или защиты на уровне хостинга;
• не используется ли устаревший плагин, который сам по себе тянет лишние риски.

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

Когда XML-RPC лучше не трогать

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

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