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

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

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

Если вы не публикуете записи через внешние клиенты, не используете Jetpack в режиме, завязанном на XML-RPC, и не подключали старые мобильные приложения WordPress, endpoint чаще всего не нужен. На практике его оставляют включённым по привычке, а потом получают лишний шум в логах и попытки подбора паролей через system.multicall.

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

Диагностика: используется ли XML-RPC на сайте

Перед изменениями проверьте, кто и как обращается к endpoint. Самый простой способ — посмотреть логи веб-сервера или запросы в панели хостинга. Если там есть обращения к /xmlrpc.php, важно понять источник: это может быть легитимный сервис или автоматический сканер.

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

• запросы к /xmlrpc.php с кодами 200, 401, 403;
• частые POST-запросы с методом system.multicall;
• обращения с одних и тех же IP с высокой частотой;
• ошибки от внешних сервисов после изменений на сайте.

Если доступ к логам ограничен, можно временно проверить endpoint вручную. Откройте https://example.com/xmlrpc.php. Нормальный ответ WordPress обычно содержит сообщение о том, что XML-RPC сервер принимает только POST-запросы. Это не значит, что endpoint безопасен или нужен; это только подтверждает, что он доступен.

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

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

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

Самый безопасный вариант для кастомной темы или mu-plugin — отключить сам endpoint и дополнительно убрать pingback. Так вы не только закрываете XML-RPC, но и снижаете риск ложных уведомлений о пингах.

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

add_filter( 'xmlrpc_enabled', '__return_false' );

add_filter( 'wp_headers', function( $headers ) {
    if ( isset( $headers['X-Pingback'] ) ) {
        unset( $headers['X-Pingback'] );
    }
    return $headers;
} );

add_filter( 'pings_open', '__return_false' );

Этот код лучше положить не в functions.php активной темы, а в маленький mu-plugin: так он не исчезнет при смене темы. Файл можно создать в wp-content/mu-plugins/disable-xmlrpc.php. Если каталога mu-plugins нет, создайте его вручную.

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

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

Для Apache обычно используют .htaccess, но если сайт работает на nginx через PHP-FPM, править нужно именно конфиг nginx, а не только .htaccess. Это частая причина, почему «вроде отключили», а endpoint по-прежнему отвечает.

Если XML-RPC нужен частично

Иногда endpoint приходится оставить: например, у вас есть старый клиент публикации или интеграция, которую нельзя быстро заменить. Тогда не стоит отключать всё подряд. Лучше ограничить доступ на уровне сервера по IP, если источник запросов фиксированный, или хотя бы убрать лишние функции в WordPress.

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

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

После отключения проверьте не только открытие URL в браузере, но и реальные сценарии.

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

Если endpoint закрыт на сервере, а WordPress всё ещё отвечает на запросы, значит правило не сработало или применяется не к тому виртуальному хосту. Если код в mu-plugin не сработал, проверьте, что файл лежит именно в mu-plugins и не содержит синтаксических ошибок.

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

Отключили XML-RPC, но сломали интеграцию

Причина обычно в том, что заранее не проверили, кто использует endpoint. Исправление простое: временно верните доступ, найдите источник запросов, затем либо переведите интеграцию на REST API, либо ограничьте доступ по IP.

Закрыли только через плагин, а нагрузка не ушла

Если плагин просто отвечает отказом уже внутри WordPress, сервер всё равно принимает запросы и тратит ресурсы на загрузку PHP. Для защиты от массовых сканов лучше блокировать /xmlrpc.php на уровне nginx или Apache.

Убрали XML-RPC, но оставили pingback

Это частая недоработка. Даже если сам endpoint закрыт, заголовок X-Pingback и открытые пинги могут продолжать создавать лишние сигналы. Убирайте их вместе.

Правили .htaccess на nginx

На nginx этот файл не управляет доступом так, как на Apache. Если сайт работает на nginx, правило нужно в конфиге сервера. Иначе вы потратите время на изменения, которые вообще не применяются.

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

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

• обновите ядро, плагины и тему до актуальных версий;
• включите двухфакторную аутентификацию для админов, если это поддерживает ваша схема входа;
• ограничьте число попыток входа и используйте сложные пароли;
• проверьте, не открыт ли REST API для лишних публичных данных;
• уберите неиспользуемые плагины и темы, а не только деактивируйте их.

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

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