Как отключить XML-RPC в WordPress и не сломать удалённый доступ

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

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

Чаще всего XML-RPC убирают не ради абстрактной «безопасности», а чтобы сократить поверхность атаки и убрать лишние запросы к /xmlrpc.php. Это особенно актуально, если на сайте нет:

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

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

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

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

Что искать в логах

Обратите внимание на:

• частые POST-запросы к /xmlrpc.php;
• повторяющиеся ошибки авторизации;
• запросы с одного и того же IP или диапазона;
• обращения от известных вам сервисов, например резервного копирования или публикации.

Если у вас есть доступ к access log, можно быстро отфильтровать обращения:

grep "xmlrpc.php" access.log

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

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

Есть три рабочих подхода: через плагин, через код и на уровне веб-сервера. Выбор зависит от того, насколько вам нужен контроль и есть ли доступ к конфигурации сервера.

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

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

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

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

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

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

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

Такой вариант особенно хорош на нагруженных сайтах: ботам не удаётся даже дойти до WordPress, а сервер не тратит ресурсы на обработку запроса.

Вариант 3: ограничить, а не отключать

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

Что может сломаться после отключения

Самая частая ошибка — выключить XML-RPC и потом удивляться, что перестала работать публикация из внешнего клиента или синхронизация с сервисом. Обычно это проявляется так:

• не отправляются записи из стороннего приложения;
• не работает удалённая публикация;
• падает интеграция старого плагина резервного копирования;
• исчезают pingback'и и trackback'и, если они были включены.

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

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

После отключения нужно проверить не только сам файл, но и связанные сценарии. Иначе можно получить ложное ощущение, что всё в порядке.

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

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

Пример проверки через curl:

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

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

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

Отключили XML-RPC, но оставили старую интеграцию

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

Спрятали проблему плагином, но не убрали источник нагрузки

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

Отключили pingback'и и сломали ожидаемое поведение

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

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

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

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

Если вам нужен более широкий набор инструментов для чистки сайта и удаления лишних технических дублей, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wpnotes.ru&utm_medium=article&utm_campaign=otklyuchit-xmlrpc-v-wordpress. Но даже с таким плагином важно понимать, что именно вы отключаете и зачем.

Короткий чек-лист перед отключением

• Проверить логи на реальные обращения к /xmlrpc.php.
• Составить список внешних сервисов, подключённых к сайту.
• Убедиться, что REST API или другой канал интеграции уже работает.
• Выбрать способ отключения: код, сервер или плагин.
• После изменений проверить доступ к сайту, админке и нужным интеграциям.

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