Как отключить XML-RPC в WordPress без потери нужной функциональности

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

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

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

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

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

Что проверить до отключения

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

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

Самый простой способ — посмотреть access log веб-сервера. Если у вас Nginx, ищите обращения к /xmlrpc.php. На Apache логика та же: нужен список запросов, а не догадки.

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

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

Ещё один рабочий тест — отправить запрос вручную и посмотреть ответ. Если XML-RPC включён, WordPress обычно отвечает на системные методы, а не отдаёт 404.

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

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

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

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

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

<?php
/**
 * Отключает XML-RPC.
 */
add_filter( 'xmlrpc_enabled', '__return_false' );

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

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

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

Если нужен mu-plugin

Для production-сайта практичнее вынести отключение в wp-content/mu-plugins/disable-xmlrpc.php. Тогда код будет загружаться всегда и не зависит от активной темы.

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

Это особенно удобно, если вы ведёте несколько сайтов и хотите одинаковое поведение без установки отдельного плагина на каждый.

Как закрыть xmlrpc.php на уровне сервера

Если задача — не только отключить функцию, но и уменьшить лишние обращения к PHP, блокируйте файл на уровне веб-сервера. Это уже не WordPress-логика, а инфраструктурная мера.

Для Nginx можно добавить правило в конфигурацию сайта:

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

На Apache обычно используют .htaccess:

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

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

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

После отключения не ограничивайтесь открытием главной страницы. Проверьте именно тот сценарий, который вы закрывали.

• Откройте /xmlrpc.php в браузере или через curl.
• Проверьте, что в логах больше нет успешных обращений к этому файлу.
• Убедитесь, что публикация через админку работает как раньше.
• Если у вас есть внешние интеграции, протестируйте их отдельно.

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

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

Если вы закрывали доступ на уровне WordPress, ожидаемое поведение — отказ в доступе или неуспешный ответ. Если блокировали на уровне сервера, запрос должен отрезаться ещё до обработки PHP.

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

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

Значит, вы не проверили зависимость заранее. Решение простое: верните фильтр назад и найдите, какой сервис использует XML-RPC. В большинстве случаев можно перевести интеграцию на REST API или заменить клиент.

Добавили код в тему, а после обновления он пропал

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

Закрыли файл на сервере, но WordPress всё равно отвечает

Проверьте, не осталось ли доступным правило в другом виртуальном хосте, и убедитесь, что блокировка стоит именно для нужного сайта. На Nginx важно, чтобы правило было в активном server block.

Поставили security-плагин и забыли, что он уже блокирует XML-RPC

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

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

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

Для сайтов, где важна чистка технического мусора и контроль дублей настроек, иногда удобнее держать такие задачи в одном инструменте. Например, Clearfy Pro от WPShop закрывает часть типовых оптимизаций и SEO-правок, но использовать его стоит только там, где вам действительно нужен набор этих функций, а не ради одной галочки. Ссылка без слеша: Clearfy Pro.

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