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

Автор: Егор Белов | Опубликовано: 25.09.2026

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

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

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

Как быстро диагностировать зависимость

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

Признаки, что XML-RPC вам может быть нужен:

используется Jetpack и в нём включены функции, завязанные на соединение с WordPress.com;
редакторы публикуют материалы из внешних клиентов или мобильного приложения WordPress;
есть старые интеграции, которые работают через XML-RPC, а не REST API;
в логах видны регулярные запросы от доверенных сервисов, а не только боты.

Что лучше: плагин, код или серверное правило

Есть три нормальных подхода. Выбор зависит от того, нужен ли вам XML-RPC частично или полностью.

Подход	Когда подходит	Плюсы	Минусы
Плагин	Нужно быстро включать/выключать без правки кода	Просто откатить, удобно для админов	Лишняя зависимость, не всегда гибко
Код в теме или mu-plugin	Нужен точечный контроль	Не зависит от интерфейса плагина	Нужно аккуратно обновлять
Правило на сервере	XML-RPC точно не нужен	Режет запросы раньше WordPress, экономит ресурсы	Можно случайно заблокировать нужный сервис

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

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

Вариант 1. Полное отключение через код

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

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

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

Вариант 2. Блокировка на уровне веб-сервера

Для Apache можно закрыть доступ к xmlrpc.php через .htaccess:

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

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

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

Это хороший вариант, если вы точно не используете XML-RPC. Он отсекает запросы до загрузки WordPress и снижает лишнюю нагрузку.

Вариант 3. Ограничить только опасные методы

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

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['system.multicall'] );
    return $methods;
} );

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

Как не сломать Jetpack и внешние сервисы

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

Если сервис критичен, не отключайте XML-RPC сразу. Сначала:

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

Если сервису нужен только доступ к контенту, возможно, он уже умеет работать через REST API. Тогда лучше перевести интеграцию на современный способ, чем держать открытым старый endpoint.

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

После изменения важно не ограничиться «сайт открывается». Проверьте именно те точки, которые зависят от XML-RPC.

Откройте /xmlrpc.php в браузере или через curl и убедитесь, что доступ закрыт или возвращается ожидаемый ответ.
Проверьте вход в админку и публикацию записей.
Если используется Jetpack, убедитесь, что он подключён и не потерял связь.
Посмотрите логи сервера: запросы к xmlrpc.php должны либо исчезнуть, либо получать отказ без нагрузки на PHP.

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

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

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

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

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

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

Добавили правило в .htaccess, но запросы всё равно проходят

Так бывает, если сайт работает не на Apache, а на Nginx, или если правило не попало в нужный блок конфигурации. Проверьте стек сервера и место, где реально обрабатываются правила. На shared-хостинге иногда проще использовать встроенную защиту панели управления.

Отключили XML-RPC через плагин, но нагрузка не снизилась

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

Блокируют весь XML-RPC, хотя нужен только один сервис

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

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

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

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

Если вам нужна более широкая чистка сайта от технического мусора, дублирующих элементов и лишних запросов, иногда удобнее делать это комплексно. Например, в Clearfy Pro есть набор настроек для технической оптимизации WordPress: https://wpshop.ru/plugins/clearfy?utm_source=wpsnippets.ru&utm_medium=article&utm_campaign=otkljuchit-xml-rpc-v-wordpress-bez-polomki-jetpack-i-vneshnih-servisov. Но даже в этом случае сначала проверьте, что именно вы отключаете, а не включайте всё подряд.

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