Как отключить xmlrpc.php в WordPress без поломки синхронизации и внешних сервисов

Автор: Кирилл Комаров | Опубликовано: 22.08.2026

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

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

Когда xmlrpc.php действительно мешает

Сам по себе файл не является уязвимостью, но он расширяет поверхность атаки. Чаще всего его трогают по трём причинам:

в логах много запросов к /xmlrpc.php с попытками подбора паролей;
на хостинге растёт число подозрительных POST-запросов;
сайт не использует старые интеграции, которым XML-RPC вообще не нужен.

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

Что может сломаться после отключения

Чаще всего страдают:

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

Если вы не уверены, откройте настройки подключённых сервисов и посмотрите, какой протокол они используют. Если в документации есть REST API — это хороший знак: отключение xmlrpc.php не должно мешать.

Диагностика: нужен ли вам xmlrpc.php

Перед изменениями проверьте, кто и как обращается к файлу. Это можно сделать по логам веб-сервера или по журналу безопасности, если он есть в панели хостинга.

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

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

Если у вас есть сомнения, временно ограничьте доступ к файлу только для проверки, а не удаляйте его сразу. Так проще откатиться.

Как отключить xmlrpc.php: рабочие варианты

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

Способ	Плюсы	Минусы	Когда выбирать
Плагин	Быстро, без правок темы	Ещё один слой логики в админке	Если нужен простой откат и нет доступа к серверу
Код в теме/плагине	Контроль в репозитории, прозрачно для разработчика	Нужно не забыть про обновления и место вставки	Если есть свой mu-plugin или кастомный плагин
Веб-сервер	Отсекает запросы до WordPress	Нужен доступ к конфигу nginx/apache	Если хотите снизить нагрузку и закрыть файл на уровне сервера

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

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

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

add_filter( 'xmlrpc_enabled', '__return_false' );

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

Вариант 2: закрыть файл на уровне nginx

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

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

После правки конфигурации проверьте синтаксис и перезагрузите nginx. Не вносите это правило в блок, который уже обрабатывается другими location-правилами, иначе можно получить неожиданный приоритет.

Вариант 3: закрыть через Apache

Если у вас Apache, используйте .htaccess или конфиг виртуального хоста. Для .htaccess подойдёт такой вариант:

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

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

Пошаговое решение без сюрпризов

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

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

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

Проверка должна быть не только визуальной. Откройте https://ваш-домен/xmlrpc.php в браузере или выполните запрос через curl. В норме вы должны увидеть отказ в доступе или ответ WordPress о том, что XML-RPC отключён.

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

Если вы закрывали доступ через nginx или Apache, код ответа должен быть не 200. Если использовали фильтр WordPress, убедитесь, что файл не отвечает как рабочий endpoint.

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

в логах больше нет успешных обращений к xmlrpc.php;
внешние сервисы продолжают публиковать или синхронизировать данные;
админка WordPress работает без ошибок;
REST API не затронут: /wp-json/ должен отвечать как раньше.

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

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

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

Заблокировали не тот endpoint

Иногда путают xmlrpc.php и REST API. Это разные механизмы. Если после правки перестали работать мобильные приложения или интеграции, проверьте, не задели ли вы /wp-json/ или правила безопасности плагина целиком.

Сломали внешний сервис, который не был задокументирован

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

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

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

Безопасность и производительность: что учесть дополнительно

Отключение xmlrpc.php не заменяет базовую защиту. Если сайт регулярно атакуют, проверьте ещё и:

ограничение попыток входа;
двухфакторную аутентификацию для админов;
актуальность ядра, тем и плагинов;
наличие WAF или правил на уровне хостинга;
отдельные права на wp-admin и wp-login.php.

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

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