Как отключить XML-RPC в WordPress без поломки мобильного приложения и интеграций

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

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

Когда XML-RPC действительно мешает

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

Отключать XML-RPC имеет смысл, если:

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

Что может зависеть от XML-RPC

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

Диагностика: как понять, можно ли его выключать

Перед изменениями проверьте не только настройки WordPress, но и реальную картину использования. Самая частая ошибка — отключить доступ, а потом искать причину, почему перестала работать публикация из внешнего сервиса, о котором давно забыли.

Проверьте логи и обращения к xmlrpc.php

Если есть доступ к логам веб-сервера, посмотрите, как часто запрашивается xmlrpc.php. Для Nginx и Apache формат логов отличается, но сама цель одна: понять, есть ли реальные обращения, а не только сканирование ботами.

grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 20

Если в логах видны только массовые запросы с разных IP и нет признаков ваших сервисов, это хороший знак. Но если среди обращений есть знакомые адреса или регулярные POST-запросы, сначала выясните источник.

Проверьте внешние сервисы

Список зависимостей обычно короткий:

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

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

Как отключить XML-RPC: три рабочих варианта

Выбор зависит от того, как у вас устроен сайт. Если нужен быстрый и обратимый способ — используйте плагин. Если вы ведёте проект кодом и конфигурацией — лучше отключить на уровне темы или mu-plugin. Если доступ к серверу есть, можно закрыть и на уровне веб-сервера.

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

Самый надёжный способ для проекта — mu-plugin. Тогда правило не исчезнет при смене темы.

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

Файл можно положить в wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную.

Вариант 2: закрыть доступ на уровне Nginx

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

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

После изменения конфигурации не забудьте проверить синтаксис и перезагрузить Nginx штатной командой вашей системы. Не вносите такие правки вслепую на продакшене без резервной копии конфигурации.

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

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

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

После отключения важно не ограничиться «страница открывается». Нужно проверить именно тот сценарий, который вы меняли.

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

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

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

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

Отключили XML-RPC, а потом сломалась публикация из приложения

Значит, зависимость была реальной. Верните доступ, проверьте источник интеграции и решите, можно ли перевести его на REST API или отказаться от него. Не оставляйте отключение «вслепую», если сервис нужен бизнесу.

Поставили плагин, но запросы продолжают доходить до сервера

Плагин может отключать обработку внутри WordPress, но не останавливать сам HTTP-запрос. Если цель — снизить нагрузку и шум в логах, лучше закрывать xmlrpc.php на уровне веб-сервера.

Сломали конфигурацию Nginx

Частая причина — правило вставили не в тот server или нарушили синтаксис блока location. Перед перезагрузкой всегда проверяйте конфиг и держите под рукой рабочую копию.

Отключили не там, где нужно

Если правило добавили в тему, оно исчезнет при обновлении или смене шаблона. Для системного ограничения используйте mu-plugin или конфигурацию сервера.

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

Отключение XML-RPC — не замена нормальной защите входа. Если на сайте идут атаки на авторизацию, дополнительно проверьте:

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

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

Что делать, если XML-RPC всё-таки нужен

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

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

Такой подход безопаснее, чем держать старый интерфейс открытым без понимания, кто им пользуется и зачем.