Как отключить XML-RPC в WordPress и не сломать нужные интеграции

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

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

Когда XML-RPC мешает, а когда его лучше оставить

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

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

Быстрая диагностика перед отключением

Перед изменениями проверьте три вещи:

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

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

Как отключить XML-RPC в WordPress: рабочие варианты

Есть три практических способа: через код, через сервер и через плагин безопасности. Для большинства сайтов самый предсказуемый вариант — код в теме или в небольшом mu-plugin. Серверный способ хорош, если вы управляете конфигурацией Nginx или Apache. Плагин удобен, но добавляет еще один слой логики, который потом нужно помнить при отладке.

Способ	Плюсы	Минусы
Код в WordPress	Прозрачно, легко откатить	Нужно не забыть про обновления темы
Правило на сервере	Режет запросы раньше WordPress	Требует доступа к конфигу сервера
Плагин	Быстро включить без кода	Еще одна зависимость и риск конфликтов

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

Самый аккуратный способ — добавить фильтр xmlrpc_enabled. Он отключает сам механизм на уровне WordPress и не требует трогать серверные настройки.

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

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

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

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

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

Для Nginx можно добавить отдельное правило:

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

Для Apache обычно используют правило в .htaccess:

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

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

Вариант 3: отключение через плагин безопасности

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

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

Пошаговое решение без лишнего риска

Ниже рабочая последовательность, которая помогает не сломать интеграции и не гадать после изменения.

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

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

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

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

Проверка через браузер или curl

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

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

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

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

Проверка логов после изменения

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

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

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

Отключили XML-RPC, а потом перестала работать публикация из старого приложения. Значит, интеграция действительно использовала XML-RPC. Верните доступ и переведите сервис на REST API или другой способ подключения.
Добавили код в тему, а после обновления он исчез. Перенесите правило в mu-plugin или отдельный мини-плагин.
Закрыли xmlrpc.php на сервере, но забыли про staging. На тестовом стенде могут быть другие интеграции и другие правила. Синхронизируйте конфигурацию отдельно.
Использовали плагин безопасности, который одновременно отключил REST API. Проверьте настройки плагина по пунктам, не включайте лишние жесткие опции без необходимости.
Смотрели только на главную страницу и не проверили внешние клиенты. XML-RPC обычно ломается не на сайте, а в стороннем приложении. Проверяйте именно сценарий использования.

Что делать, если XML-RPC нужен частично

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

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

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

Отключение XML-RPC само по себе не делает сайт «защищенным», но убирает один из популярных векторов шумной активности. Это полезно еще и для производительности: меньше бесполезных запросов — меньше нагрузки на PHP и базу, особенно если сайт регулярно атакуют перебором.

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

Если вам нужен более широкий набор инструментов для чистки сайта, отключения дублей и технической оптимизации, можно посмотреть в сторону решений уровня Clearfy Pro: https://wpshop.ru/plugins/clearfy?utm_source=wptests.ru&utm_medium=article&utm_campaign=otklyuchit-xmlrpc-v-wordpress. Но даже в этом случае сначала проверьте, не решается ли ваша задача одним понятным правилом в коде или на сервере.

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