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

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

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

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

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

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

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

Самый полезный шаг — посмотреть логи веб-сервера. Если доступ к логам есть, ищите запросы к /xmlrpc.php и оцените частоту, IP-адреса и user-agent. Это быстро покажет, идёт ли трафик от ваших сервисов или это просто массовый перебор.

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

• частые POST-запросы к /xmlrpc.php;
• одинаковые IP с большим числом попыток;
• подозрительные user-agent без привязки к реальному сервису;
• ошибки 401, 403, 405 или 500 после обращений к endpoint.

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

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

Пошаговое решение через код

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

Вариант 1: полностью отключить XML-RPC

<?php
/**
 * Plugin Name: Disable XML-RPC
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

Создайте файл, например wp-content/mu-plugins/disable-xmlrpc.php. Если папки mu-plugins нет, создайте её вручную. После этого WordPress перестанет обслуживать XML-RPC на уровне ядра.

Вариант 2: оставить XML-RPC, но ограничить часть методов

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

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

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

Пошаговое решение через сервер

Если у вас Nginx или Apache и есть доступ к конфигу, блокировка на уровне сервера часто предпочтительнее. Запросы будут отсекаться раньше, чем дойдут до PHP и WordPress.

Nginx

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

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

Apache

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

Если у вас используется .htaccess, убедитесь, что правило не конфликтует с уже существующими директивами безопасности или кэша.

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

Проверка должна быть не формальной, а практической. После внедрения откройте /xmlrpc.php в браузере и отправьте тестовый POST-запрос. В идеале вы должны получить отказ на уровне сервера или пустой/ошибочный ответ без выполнения WordPress-логики.

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

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

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

Если блокировка настроена на сервере, вы увидите отказ без участия WordPress. Если отключение сделано через фильтр xmlrpc_enabled, ответ может отличаться, но endpoint всё равно не должен работать как раньше.

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

Отключили XML-RPC, а потом сломался внешний сервис

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

Поставили плагин, но endpoint всё ещё отвечает

Так бывает, если плагин только ограничивает часть методов или конфликтует с серверным правилом. Проверяйте, что именно делает плагин: отключает XML-RPC полностью или только pingback. Иногда нужно убрать дублирующее правило в другом месте.

Добавили правило в .htaccess, но оно не сработало

Причина может быть в том, что сайт работает на Nginx, а .htaccess вообще не используется. Либо правило стоит не в том блоке. В таких случаях нужно править конфиг веб-сервера, а не WordPress.

Сломали не XML-RPC, а REST API

Это типичная путаница. xmlrpc.php и REST API — разные механизмы. Если после изменений перестали работать мобильные приложения или интеграции, проверьте, не отключили ли вы лишнее в плагине безопасности или в настройках кэша/фаервола.

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

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

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

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

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

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

В рабочем проекте полезно прямо записать: кто использует endpoint, зачем он нужен, где находится правило блокировки и как его временно снять. Это экономит время, когда сайт передают другому разработчику или агентству.