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

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

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

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

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

Типовые признаки, что XML-RPC ещё нужен

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

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

Начните с веб-сервера и access log. Если у вас Nginx или Apache, ищите обращения к xmlrpc.php за последние дни. Это самый надёжный способ понять, есть ли живые клиенты, а не гадать по списку плагинов.

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

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

<?php
/**
 * Plugin Name: XML-RPC request logger
 */
add_action('xmlrpc_call', function ($method) {
    error_log('XML-RPC method called: ' . $method);
});

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

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

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

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

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

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

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

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

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

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

Для Apache аналогичный эффект обычно делают через правила в .htaccess, но на практике лучше использовать серверный конфиг, если он доступен. Важно: если у вас есть легитимные клиенты, этот способ их тоже отключит.

Вариант 3: оставить XML-RPC, но ограничить риск

Если интерфейс нужен, не отключайте его полностью. Вместо этого проверьте, не включён ли брутфорс по system.multicall, и настройте ограничение запросов на уровне WAF, fail2ban или хостинга. Это не универсальное решение, но оно лучше, чем ломать рабочую интеграцию.

Чем заменить XML-RPC в типичных сценариях

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

Публикация из внешнего сервиса

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

Мобильное приложение WordPress

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

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

После отключения нужно проверить не только открытие страницы /xmlrpc.php, но и реальные сценарии, ради которых он мог использоваться.

• Откройте https://example.com/xmlrpc.php в браузере. В идеале вы должны получить отказ в доступе или пустой ответ без рабочей формы метода.
• Проверьте access log: новых обращений к xmlrpc.php быть не должно.
• Если есть мобильное приложение, попробуйте выполнить вход и создать черновик.
• Если есть внешняя интеграция, прогоните тестовую публикацию или синхронизацию.

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

curl -i -X POST https://example.com/xmlrpc.php \
  -H 'Content-Type: text/xml' \
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

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

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

Отключили XML-RPC, но сломали Jetpack или публикацию из внешнего сервиса

Причина почти всегда одна: сервис всё ещё использовал XML-RPC, а замены не было. Решение — либо вернуть доступ, либо перевести интеграцию на REST API, если это поддерживается.

Добавили код в тему, а потом сменили тему и защита пропала

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

Заблокировали файл на сервере, но забыли про кеш и WAF

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

Сразу поставили «всё запрещено», не проверив логи

Это приводит к ложным срабатываниям. Сначала соберите факты: кто и как обращается к xmlrpc.php, потом отключайте или ограничивайте доступ.

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

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

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

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

• Проверили access log и убедились, что XML-RPC не используется постоянно.
• Проверили мобильные приложения и внешние интеграции.
• Выбрали способ отключения: mu-plugin или серверный конфиг.
• Очистили кеш после изменений.
• Протестировали публикацию, вход и синхронизацию в реальном сценарии.

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