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

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

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

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

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

Что проверить до изменений

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

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

Диагностика: как понять, кто обращается к xmlrpc.php

Самый практичный способ — посмотреть access log веб-сервера. Если доступ к логам есть, ищите строки с xmlrpc.php. На уровне WordPress это не всегда видно, потому что запрос может даже не дойти до полноценной загрузки темы и плагинов.

# Пример для grep по access.log
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50

Если у вас Apache, логика та же: ищите обращения к xmlrpc.php, частоту и повторяющиеся IP. Важен не только факт запросов, но и их тип. Если это одиночные обращения от известных сервисов — это один сценарий. Если это массовые POST-запросы с попытками перебора — другой.

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

Подходы к решению: что выбрать в зависимости от задачи

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

Пошаговое решение: ограничиваем XML-RPC через код

Ниже пример, который блокирует опасные методы, связанные с массовыми попытками авторизации и лишними возможностями, но не ломает сам endpoint целиком. Код можно добавить в mu-plugin или в отдельный мини-плагин.

<?php
/**
 * Plugin Name: XML-RPC Method Restriction
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_filter( 'xmlrpc_methods', function( $methods ) {
    // Убираем методы, которые чаще всего не нужны на обычном сайте.
    unset( $methods['system.multicall'] );
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );

    return $methods;
} );

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

Если нужен более жёсткий контроль

Можно дополнительно ограничить доступ по IP. Это полезно, если XML-RPC нужен только для конкретного сервиса с фиксированным адресом. Важно: такой вариант работает только если IP действительно стабилен.

<?php
add_filter( 'xmlrpc_enabled', function( $enabled ) {
    if ( isset( $_SERVER['REMOTE_ADDR'] ) ) {
        $allowed_ips = array(
            '203.0.113.10',
            '203.0.113.11',
        );

        if ( in_array( $_SERVER['REMOTE_ADDR'], $allowed_ips, true ) ) {
            return true;
        }
    }

    return false;
} );

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

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

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

• откройте /xmlrpc.php в браузере — ответ не должен быть обычной рабочей страницей сайта;
• проверьте мобильное приложение WordPress, если вы им пользуетесь;
• попробуйте публикацию через внешний клиент или интеграцию, которая была подключена раньше;
• снова посмотрите access log и убедитесь, что массовые запросы к endpoint не приводят к ошибкам авторизации или всплеску нагрузки;
• проверьте, не появились ли новые ошибки в логах PHP и веб-сервера после изменения.

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

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

Полностью отключили XML-RPC, не проверив интеграции

Это самая частая ошибка. Сайт может выглядеть нормально, но внешняя публикация или мобильный клиент перестанут работать. Исправление простое: верните endpoint, но ограничьте методы или доступ по IP.

Сделали блокировку на уровне WordPress, но забыли про серверный кеш

Если у вас агрессивный кеш или reverse proxy, старые ответы могут продолжать отдаваться некоторое время. После изменения правил очистите кеш на всех уровнях: плагин кеширования, сервер, CDN.

Поставили слишком жёсткий whitelist IP

Это ломает интеграции при смене адресов у внешнего сервиса. Если IP не статичен, такой подход лучше не использовать. В этом случае безопаснее ограничить методы и добавить защиту на уровне WAF.

Проверяли только в админке

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

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

Если цель — не просто «закрыть что-то лишнее», а снизить риск и нагрузку, держите несколько правил:

• не отключайте XML-RPC вслепую на сайте с внешними интеграциями;
• сначала убирайте system.multicall и pingback.ping;
• если нужен доступ только одному сервису, ограничивайте его по IP на уровне сервера или WAF;
• после изменений смотрите не только фронтенд, но и логи авторизации, 403/401 и ошибки PHP;
• не ставьте тяжёлые плагины ради одной настройки, если задачу можно решить кодом или правилом сервера.

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

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