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

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

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

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

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

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

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

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

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

Пример для Nginx:

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

Если у вас есть доступ к аналитике или WAF, проверьте, не завязаны ли на XML-RPC легитимные запросы. Отдельно стоит посмотреть, не используются ли pingback-уведомления: они тоже идут через этот механизм.

Что важно не перепутать

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

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

Есть три рабочих подхода: через код, через сервер и через плагин. Для большинства сайтов самый предсказуемый вариант — код в теме или в небольшом must-use плагине.

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

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

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

Если хотите не просто отключить API, а ещё и отдать 403 на прямой доступ к xmlrpc.php, используйте дополнительную проверку:

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

add_action( 'init', function () {
    if ( defined( 'XMLRPC_REQUEST' ) && XMLRPC_REQUEST ) {
        status_header( 403 );
        exit;
    }
} );

На практике первого варианта часто достаточно. Второй полезен, если нужно жёстко закрыть точку входа и вы уверены, что XML-RPC нигде не используется.

Вариант 2: закрыть xmlrpc.php на уровне сервера

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

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

Для Apache обычно используют правило в .htaccess:

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

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

Вариант 3: отключить только pingback и trackback

Иногда XML-RPC нужен частично, но pingback и trackback — нет. Тогда не рубите всё целиком. Можно отключить уведомления и убрать лишнюю поверхность атаки.

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

add_filter( 'pings_open', '__return_false' );

Это не универсальная защита, но для некоторых сайтов — разумный компромисс между совместимостью и безопасностью.

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

Проверка должна быть не только визуальной. Откройте /xmlrpc.php в браузере или через curl. Если всё отключено корректно, вы не должны видеть обычный ответ WordPress с сообщением о том, что XML-RPC сервер принимает POST-запросы.

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

Ожидаемый результат зависит от способа блокировки: это может быть 403 Forbidden на уровне сервера или другой отказ, если вы отключили XML-RPC через WordPress. Главное — отсутствие успешного ответа с доступным endpoint.

Дальше проверьте функциональные сценарии:

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

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

Отключили не XML-RPC, а REST API

Такое бывает, когда в коде или в плагине безопасности включают слишком агрессивные настройки. Если перестал работать редактор блоков или внешние интеграции, проверьте, не заблокирован ли /wp-json/ и не стоит ли лишний фильтр на REST.

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

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

Поставили плагин, который отключает слишком много

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

Не проверили кэш и WAF

Иногда запросы к xmlrpc.php продолжают проходить через CDN или защиту хостинга, а вы видите старое поведение из-за кэша правил. После изменений очистите кэш на всех уровнях: плагин, сервер, CDN, WAF.

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

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

Если у вас много технических дублей, лишних endpoint-ов и мусорных запросов, имеет смысл посмотреть в сторону комплексной чистки сайта. Например, Clearfy Pro от WPShop закрывает часть типовых задач по удалению дублей и технической оптимизации: https://wpshop.ru/plugins/clearfy. Но даже в этом случае сначала проверьте, не затронет ли настройка нужные интеграции.

Мини-чек-лист перед публикацией изменений

• Проверили логи и убедились, что XML-RPC не нужен.
• Выбрали один способ отключения, а не несколько конфликтующих сразу.
• Убедились, что REST API и редактор блоков работают.
• Проверили /xmlrpc.php через браузер или curl.
• Очистили кэш и обновили правила WAF/CDN, если они есть.

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