Как отключить XML-RPC в WordPress на VDS и проверить, что сайт не сломался

Автор: Дмитрий Крылов | Опубликовано: 09.08.2026

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

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

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

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

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

Что обычно ломается после отключения

Чаще всего проблемы проявляются не сразу, а только в конкретном сценарии: не отправляется запись из внешнего клиента, перестаёт работать синхронизация с приложением, не проходит pingback/trackback, если они ещё используются. Для WooCommerce это обычно не критично, если сторонние сервисы не завязаны на XML-RPC.

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

Перед изменениями посмотрите access log веб-сервера. На Nginx это обычно /var/log/nginx/access.log, на Apache — соответствующий access log виртуального хоста. Ищите запросы к /xmlrpc.php и оцените частоту. Если это только случайные боты с ошибками 403/404, отключение безопасно. Если видите регулярные обращения от ваших сервисов или известных IP, сначала разберитесь с ними.

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

Если логов много, полезно посмотреть не только сам факт обращения, но и User-Agent, IP и код ответа. Это помогает отличить реальный сервис от массового сканирования.

awk '$7 ~ /xmlrpc\.php/ {print $1, $4, $6, $7, $9, $12}' /var/log/nginx/access.log | tail -n 30

Пошаговое решение: как отключить XML-RPC

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

Способ	Когда подходит	Плюсы	Минусы
Код в теме или mu-plugin	Нужен быстрый и прозрачный контроль	Просто проверить, легко откатить	Нужно не забыть про обновления темы
Правило на Nginx/Apache	Есть доступ к конфигу сервера	Блокирует запрос раньше WordPress	Требует доступа к серверу и перезагрузки конфигурации
Плагин безопасности	Нужна настройка без правок кода	Удобно для администраторов	Лишний плагин и риск конфликтов

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

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

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

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

<?php
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

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

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

Если сайт работает на Nginx, можно отдать 444 или 403 для /xmlrpc.php. Это полезно, когда вы хотите отсечь запросы ещё до загрузки WordPress.

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

После изменения конфигурации проверьте синтаксис и перезагрузите Nginx. Команды зависят от дистрибутива, но базовый сценарий выглядит так:

nginx -t
systemctl reload nginx

На Apache можно использовать правило в .htaccess или конфигурации виртуального хоста:

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

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

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

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

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

Проверка через curl:

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

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

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

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

Если у вас есть мониторинг, полезно посмотреть, не выросло ли число ошибок 4xx после изменения. Иногда внешняя система продолжает стучаться в XML-RPC и это видно только в логах.

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

Отключили XML-RPC в теме, а потом сменили тему

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

Заблокировали XML-RPC, но забыли про интеграцию

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

Поставили плагин безопасности и не поняли, что именно он блокирует

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

Ожидали ускорения сайта, а его не увидели

XML-RPC сам по себе не делает сайт заметно быстрее. Его отключение — это про безопасность и уменьшение лишнего трафика, а не про магическую оптимизацию. Если цель именно производительность, смотрите в сторону кэша, object cache, PHP-FPM и оптимизации запросов.

Практические советы для VDS и продакшена

На VDS удобно разделять ответственность: WordPress отвечает за логику, а веб-сервер — за грубую фильтрацию. Если у вас есть доступ к конфигу Nginx или Apache, лучше закрыть xmlrpc.php там, а в WordPress оставить дополнительный фильтр как запасной слой. Это не конфликтует и помогает, если кто-то случайно уберёт одно из правил.

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

Для контроля изменений держите под рукой быстрый откат: резервную копию конфигурации Nginx/Apache, отдельный mu-plugin с одним фильтром и список сервисов, которые должны продолжать работать. Тогда отключение XML-RPC не превратится в долгий поиск причины, если что-то неожиданно перестанет отправляться.

Если вы хотите дальше уменьшить поверхность атаки на WordPress-сайте на хостинге или VDS, логично проверить и другие публичные точки: /wp-login.php, REST-эндпоинты, комментарии, неиспользуемые формы и лишние плагины. Но каждую из этих мер лучше внедрять отдельно и с проверкой, чтобы не сломать рабочие сценарии.

⭐⭐⭐⭐⭐