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

Автор: Тимур Никитин | Опубликовано: 20.08.2026

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

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

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

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

Типичные причины отключения

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

Когда отключать не стоит

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

Диагностика: кто обращается к xmlrpc.php

Перед изменениями посмотрите логи веб-сервера или хотя бы статистику запросов на уровне хостинга. Ищите обращения к /xmlrpc.php. Если у вас включён доступ к access log, этого обычно достаточно, чтобы понять, это реальные клиенты или просто шум.

Пример поиска в логах Apache/Nginx:

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

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

<?php
/**
 * Plugin Name: XML-RPC Request Logger
 */

add_action('xmlrpc_call', function ($method) {
    error_log('XML-RPC method: ' . $method);
});

Этот вариант полезен только для диагностики и только если у вас включён error_log. Для постоянной работы он не нужен.

Как отключить XML-RPC безопасно

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

Способ	Плюсы	Минусы
Код в теме или mu-plugin	Прозрачно, легко откатить	Нужно не забыть про тестирование
Плагин безопасности	Быстро включить без кода	Лишняя зависимость от плагина
Правило на сервере	Отсекает запросы раньше WordPress	Нужно аккуратно править конфиг

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

Самый понятный способ — вернуть false в фильтре xmlrpc_enabled. Код лучше класть в mu-plugin, чтобы он не зависел от темы.

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

add_filter('xmlrpc_enabled', '__return_false');

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

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

Если вы уверены, что endpoint не нужен вообще, можно отрезать его раньше WordPress. Для Nginx это обычно делается отдельным правилом в конфигурации сайта:

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

Для Apache можно использовать правило в .htaccess, но только если ваш хостинг действительно читает этот файл и вы понимаете, как он сочетается с текущими правилами WordPress:

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

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

Вариант 3: использовать плагин, если нужен быстрый откат

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

Пошаговое решение для production-сайта

Проверьте логи и убедитесь, что через XML-RPC не идут нужные запросы.
Сделайте резервную копию файлов и базы.
Добавьте фильтр xmlrpc_enabled в mu-plugin или в отдельный мини-плагин.
Очистите кеш, если стоит page cache или CDN.
Проверьте доступ к /xmlrpc.php вручную и через внешние интеграции.

Если нужен аккуратный мини-плагин, используйте такой шаблон:

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Отключает XML-RPC на сайте WordPress.
 * Version: 1.0.0
 */

if (!defined('ABSPATH')) {
    exit;
}

add_filter('xmlrpc_enabled', '__return_false');

После активации этого кода WordPress должен перестать отвечать на XML-RPC-запросы штатным образом. Это не отменяет того, что на уровне сервера endpoint всё ещё может быть доступен как URL, но сам WordPress уже не будет его обслуживать.

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

Проверка нужна не только на уровне браузера. Откройте https://example.com/xmlrpc.php в браузере — вы не увидите «нормальную» страницу WordPress, и это ожидаемо. Но этого недостаточно: endpoint может отвечать кодом 405, 403 или другим поведением в зависимости от сервера и правил.

Практичнее проверить через XML-RPC-клиент или хотя бы через curl с тестовым запросом. Пример:

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

Если вы отключали XML-RPC на уровне WordPress, важно убедиться, что:

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

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

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

Отключили XML-RPC и потеряли интеграцию

Это самая частая история. Причина обычно в том, что никто не проверил, кто именно использует endpoint. Решение простое: вернуть фильтр назад, зафиксировать реальный источник запросов и уже потом искать альтернативу — REST API, webhook или прямую интеграцию через плагин.

Поставили правило в .htaccess, но оно не сработало

На части хостингов Apache может быть настроен так, что .htaccess не влияет на нужный участок, либо правила перезаписываются другими блоками. В таком случае проверьте конфигурацию сервера или перенесите блокировку в Nginx/панель хостинга.

Оставили кеш и думают, что всё сломалось

После отключения XML-RPC нужно чистить не только page cache, но и CDN, если он есть. Иначе вы можете видеть старое поведение или старые ответы из кеша и сделать неправильный вывод о результате.

Смешали XML-RPC и REST API

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

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

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

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

Короткий чек-лист перед отключением

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

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