XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом получают лишнюю поверхность атаки и шум в логах. Если вы не используете мобильное приложение WordPress, внешние публикации или старые интеграции, этот интерфейс обычно можно закрыть точечно: на уровне веб-сервера и на уровне самого WordPress.
Ниже — не абстрактная теория, а рабочая схема: сначала быстро диагностируем, нужен ли вам XML-RPC вообще, затем отключаем его без лишних побочных эффектов и проверяем, что сайт продолжает работать как раньше.
Когда XML-RPC действительно мешает
Проблема обычно проявляется не в интерфейсе админки, а в фоне: в логах растёт число запросов к /xmlrpc.php, появляются попытки подбора паролей через system.multicall, а некоторые серверы начинают тратить ресурсы на обработку бесполезных обращений. На слабых хостингах это заметно по нагрузке, на нормальных — по логам и WAF-событиям.
Что проверить перед отключением
- Используете ли вы мобильное приложение WordPress для публикации и редактирования.
- Есть ли внешние сервисы, которые подключаются к сайту через XML-RPC.
- Не завязаны ли на XML-RPC старые интеграции с редакторами или планировщиками публикаций.
- Есть ли в логах регулярные обращения к
xmlrpc.phpс ошибками авторизации.
Если ничего из этого не нужно, отключение обычно безопасно. Если сомневаетесь, сначала ограничьте доступ на уровне сервера, а не удаляйте файл и не правьте ядро.
Диагностика: как понять, что XML-RPC используется
Самый практичный способ — посмотреть логи веб-сервера и проверить, есть ли реальные обращения не только от ботов. Для Apache и Nginx это делается по-разному, но смысл один: ищем запросы к /xmlrpc.php и смотрим, кто их делает и с каким статусом.
# Пример для поиска в access.log
# Apache/Nginx — адаптируйте путь к своему лог-файлу
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50
Если вы видите только массовые попытки с разных IP и без понятного источника, это хороший кандидат на отключение. Если же в логах есть обращения от вашего приложения или внешнего сервиса, сначала перенастройте интеграцию.
Пошаговое решение: закрываем XML-RPC без поломки сайта
Есть два нормальных пути: блокировка на уровне веб-сервера и отключение через WordPress-фильтр. На практике лучше использовать оба, если у вас есть доступ к конфигурации сервера. Тогда даже при обходе одного уровня второй продолжит блокировать запрос.
Вариант 1: блокировка через .htaccess
Если сайт работает на Apache, добавьте правило в .htaccess выше стандартного блока WordPress. Это не удаляет файл xmlrpc.php, а просто запрещает к нему доступ.
<Files xmlrpc.php>
Require all denied
</Files>
Для старых конфигураций Apache 2.2 встречается вариант с Order Deny,Allow, но на современных серверах лучше использовать Require all denied. После правки перезапуск Apache обычно не нужен, но изменения вступают в силу сразу после сохранения файла.
Вариант 2: отключение через PHP-фильтр
Если вы не хотите трогать конфиг веб-сервера или используете Nginx без .htaccess, можно отключить XML-RPC через тему или, что лучше, через небольшой mu-plugin. Так решение не потеряется при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter('xmlrpc_enabled', '__return_false');
Сохраните файл как disable-xmlrpc.php в wp-content/mu-plugins/. Если папки mu-plugins нет, создайте её вручную. Такой вариант хорош тем, что не зависит от активной темы и включается автоматически.
Вариант 3: блокировка через Nginx
Если сайт работает на Nginx, правило добавляют в конфигурацию виртуального хоста. Это особенно полезно, если вы хотите отсечь запросы ещё до передачи их в PHP.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
После изменения конфигурации проверьте синтаксис и перезагрузите Nginx штатной процедурой вашего сервера. Не правьте файлы наугад: ошибка в конфиге может положить весь сайт, а не только XML-RPC.
Что выбрать: сервер, PHP или плагин
Если нужна короткая рабочая схема, вот сравнение подходов.
| Способ | Где применять | Плюсы | Минусы |
|---|---|---|---|
| .htaccess / Nginx | Есть доступ к серверной конфигурации | Блокирует запросы до PHP, снижает нагрузку | Нужно аккуратно править конфиг |
| mu-plugin | Нет доступа к серверу или нужен переносимый вариант | Просто внедрить, не зависит от темы | Запрос всё равно доходит до WordPress |
| Обычный плагин | Нужна настройка через админку | Удобно для редакторов и админов | Лишняя зависимость и ещё один плагин в системе |
Если цель — именно безопасность и снижение шума, серверная блокировка предпочтительнее. Если цель — быстрое и переносимое решение без доступа к серверу, mu-plugin обычно достаточно.
Проверка результата после внедрения
После отключения не ограничивайтесь открытием главной страницы. Проверьте сам endpoint напрямую и посмотрите, как отвечает сервер.
curl -I https://example.com/xmlrpc.php
Ожидаемый результат зависит от выбранного способа. При блокировке на сервере вы обычно увидите 403 Forbidden. При отключении через WordPress может быть другой ответ, но главное — отсутствие успешной обработки XML-RPC-запросов.
Дополнительно проверьте:
- вход в админку и публикацию записей;
- работу REST API, если он используется в теме или плагинах;
- отсутствие ошибок в error.log после изменения конфигурации;
- снижение числа обращений к
xmlrpc.phpв access.log.
Частые ошибки и как их исправить
Сломали мобильное приложение WordPress
Это ожидаемо, если приложение действительно использовало XML-RPC. Решение простое: либо возвращаете доступ, либо переводите рабочий процесс на другой способ публикации. Не пытайтесь «починить» это частичным разрешением без понимания, какие методы нужны приложению.
Отключили не там, где нужно
Если вы добавили фильтр в активную тему, а потом сменили тему, защита исчезнет. Для постоянного решения используйте mu-plugin или серверную блокировку.
Перепутали XML-RPC и REST API
Это разные механизмы. Отключение xmlrpc.php не должно ломать REST API, но если после правок перестали работать блоки, интеграции или редактор, ищите ошибку в конфиге сервера или в другом плагине, а не в XML-RPC как таковом.
Заблокировали файл, но не убрали старые правила
Иногда в .htaccess или конфиге Nginx остаются конфликтующие директивы от старых плагинов безопасности. Если ответ на /xmlrpc.php ведёт себя странно, проверьте все уровни: сервер, mu-plugins, обычные плагины, кэширующие прокси.
Практические советы по безопасности и производительности
Если вы закрываете XML-RPC ради безопасности, не останавливайтесь на одном файле. Проверьте, не включены ли у вас устаревшие интеграции, неиспользуемые плагины и лишние внешние точки входа. На загруженных сайтах полезно дополнительно ограничить частоту запросов к логину и включить нормальную защиту от брутфорса на уровне сервера или WAF.
Для сайтов, где регулярно приходится чистить технический мусор и дубли, удобно держать под рукой инструменты вроде Clearfy Pro: он помогает закрывать типовые SEO- и технические хвосты, не распыляя настройки по десятку плагинов. Но даже с такими инструментами серверная блокировка XML-RPC остаётся самым прямым решением, если интерфейс вам не нужен.
Если вы работаете с конфигурацией аккуратно, этот сценарий занимает немного времени и даёт понятный результат: меньше лишнего трафика, меньше шума в логах и меньше точек атаки без вмешательства в ядро WordPress.