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

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

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

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

Но перед отключением проверьте, не завязаны ли на него:

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

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

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

Проверка снаружи

Можно быстро проверить, отвечает ли endpoint. Если он доступен, это ещё не значит, что его нужно отключать, но это отправная точка для диагностики.

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

Обычно вы увидите ответ сервера. Если после отключения всё настроено корректно, запрос должен возвращать 403 или 404 в зависимости от способа блокировки.

Проверка зависимостей

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

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

Есть два рабочих подхода: через код в WordPress и через веб-сервер. Если вы управляете сайтом сами, я бы начинал с кода — так проще откатить изменения. Если у вас жёсткая серверная политика, можно закрыть доступ на уровне nginx или Apache.

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

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

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

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

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['system.multicall'] );
    unset( $methods['pingback.ping'] );
    return $methods;
} );

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

Вариант 2. Заблокировать xmlrpc.php на сервере

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

Для nginx:

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

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

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

Если у вас сайт за CDN или прокси, убедитесь, что правило применяется именно на том слое, который реально получает запросы. Иначе вы увидите «запрет» в конфиге, но endpoint останется доступным.

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

Проверка должна быть не только технической, но и функциональной. Снаружи запрос к xmlrpc.php должен быть заблокирован, а ваши рабочие сценарии — продолжить работать.

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

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

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

Отключили XML-RPC, но забыли про бэкапы

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

Блокируют только в WordPress, но оставляют открытым на сервере

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

Сразу режут весь доступ без теста

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

Путают XML-RPC и REST API

Отключение xmlrpc.php не отключает REST API. Если у вас есть отдельная задача по защите REST, это решается другими правилами и не связано напрямую с XML-RPC.

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

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

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

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

В этом случае не стоит открывать его для всех. Логичнее ограничить доступ по IP на уровне сервера или заменить интеграцию на более современный способ. Если сервис поддерживает REST API или webhook, это обычно более предсказуемый вариант, чем держать открытым старый endpoint.

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