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

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

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

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

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

Сигналы, что XML-RPC можно отключать:

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

Что может сломаться

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

Диагностика: нужен ли вам XML-RPC сейчас

Перед изменениями проверьте, кто вообще обращается к xmlrpc.php. На хостинге с доступом к логам это можно увидеть по access log. Если доступа к логам нет, хотя бы откройте сайт в браузере и проверьте ответ endpoint вручную.

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

Нормальный ответ не означает, что XML-RPC нужен. Он лишь показывает, что endpoint доступен. Если хотите понять, есть ли реальные вызовы, ищите в логах строки с POST /xmlrpc.php.

Ещё один практичный тест — временно отключить endpoint на тестовой копии и проверить:

• работает ли публикация из мобильного приложения WordPress;
• не отвалилась ли синхронизация с Jetpack;
• не используются ли внешние сервисы автопостинга;
• не завязаны ли на XML-RPC старые интеграции CRM или планировщики публикаций.

Как отключить XML-RPC: три рабочих подхода

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

Вариант 1: отключить через фильтр

Самый простой способ — вернуть false в фильтре xmlrpc_enabled. Код лучше класть не в functions.php активной темы, а в небольшой mu-plugin или свой мини-плагин, чтобы правило не исчезло после смены темы.

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

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

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

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

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

Для Apache можно использовать правило в .htaccess, если хостинг это позволяет:

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

Этот вариант полезен, когда вы хотите уменьшить нагрузку и убрать лишние запросы ещё до WordPress. Но если у вас есть зависимые интеграции, сначала проверьте их на тестовом стенде.

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

Иногда XML-RPC нужен, а pingback и trackback — нет. Тогда можно точечно убрать именно эти механизмы. Это не заменяет полное отключение XML-RPC, но снижает мусор и часть спама.

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

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

Пошаговое решение для боевого сайта

1. Сделайте резервную копию файлов и базы.
2. Проверьте логи на обращения к /xmlrpc.php.
3. На тестовой копии отключите XML-RPC через xmlrpc_enabled.
4. Проверьте публикацию из админки, мобильных приложений и внешних сервисов.
5. Если всё работает, перенесите изменение на прод.
6. При массовых запросах добавьте блокировку на уровне веб-сервера.

Если у вас есть доступ только к WordPress, начните с mu-plugin. Это надёжнее, чем правка темы, и проще в поддержке. Для mu-plugin достаточно файла в wp-content/mu-plugins/.

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

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

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

curl -X POST https://example.com/xmlrpc.php \
  -d '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName></methodCall>'

Ожидаемое поведение зависит от способа блокировки:

• при отключении через фильтр WordPress должен вернуть ошибку или отказ в обработке;
• при блокировке на сервере запрос должен завершаться без передачи в PHP;
• в логах не должно оставаться регулярных успешных обращений к endpoint.

Дополнительно проверьте:

• вход в админку и публикацию записей;
• работу Jetpack, если он установлен;
• мобильное приложение WordPress, если вы им пользуетесь;
• отсутствие новых ошибок в error log после изменения.

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

Отключили XML-RPC в теме

Если правило лежит в functions.php, оно исчезнет при смене темы. Для технических ограничений это плохая точка хранения. Перенесите код в mu-plugin или отдельный плагин.

Закрыли endpoint, но забыли про зависимые сервисы

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

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

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

Блокировка на сервере конфликтует с кешем или WAF

Иногда правило уже есть в CDN, WAF или панели хостинга, а вы добавляете ещё одно в .htaccess или nginx. В итоге сложно понять, где именно срабатывает блок. Сначала проверьте, нет ли уже готового запрета на уровне защиты хостинга.

Что ещё стоит сделать для безопасности

Если вы отключаете XML-RPC ради снижения атак, не ограничивайтесь одним endpoint. Проверьте, не открыт ли у вас лишний доступ к wp-login.php, не используются ли слабые пароли и нет ли устаревших плагинов. XML-RPC часто просто подсвечивает общую проблему с гигиеной сайта.

Для сайтов с высокой нагрузкой полезно дополнительно:

• ограничить частоту запросов к логину на уровне WAF или плагина безопасности;
• убрать ненужные публичные endpoint’ы;
• следить за логами 403/404, чтобы видеть всплески сканирования;
• обновлять ядро, темы и плагины без задержек.

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

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