XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом получают лишнюю поверхность атаки и ненужные запросы к /xmlrpc.php. Если вы не используете старые мобильные клиенты, внешние сервисы публикации или удалённые интеграции, этот механизм обычно можно отключить без потерь. Но делать это стоит не вслепую: сначала проверьте, кто именно обращается к XML-RPC, а потом уже режьте доступ.
Когда XML-RPC реально мешает
Проблема обычно проявляется не как одна большая ошибка, а как набор мелких симптомов: в логах появляются повторяющиеся POST-запросы, хостинг ругается на подозрительную активность, а брутфорс-атаки через system.multicall начинают съедать ресурсы. На небольших сайтах это заметно по всплескам нагрузки, на более крупных — по шуму в логах и лишним обращениям к PHP.
При этом отключать XML-RPC «в лоб» не стоит, если вы используете:
- старое приложение WordPress для публикации с телефона;
- Jetpack и похожие сервисы, которые могут опираться на XML-RPC в отдельных сценариях;
- внешние инструменты автопостинга, которые не перешли на REST API;
- интеграции, где удалённая публикация настроена именно через XML-RPC.
Диагностика: кто обращается к xmlrpc.php
Перед изменениями посмотрите, есть ли вообще легитимный трафик. В access-логах ищите запросы к /xmlrpc.php. Если у вас Nginx, это можно сделать через grep по логам; если Apache — аналогично по access log. Важно понять не только факт обращений, но и их частоту.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если у вас есть доступ к панели хостинга, проверьте статистику запросов по URL. Частые POST-запросы к XML-RPC без понятного источника — хороший повод отключить его полностью или хотя бы ограничить на уровне веб-сервера.
Что считать нормой
Единичные обращения от ваших собственных сервисов — это нормально. Подозрительно выглядит постоянный поток запросов с разных IP, особенно если в логах повторяется system.multicall или попытки авторизации. В таком случае отключение XML-RPC — не косметическая мера, а реальное снижение нагрузки и риска.
Как отключить XML-RPC без плагинов
Есть два рабочих подхода: запрет на уровне WordPress и запрет на уровне веб-сервера. Первый проще внедрить в тему или mu-plugin, второй жёстче и разгружает PHP. Если нужен быстрый и безопасный старт, начните с фильтра WordPress.
Вариант 1: отключение через фильтр
Добавьте код в functions.php дочерней темы или, лучше, в отдельный mu-plugin. Так вы не потеряете настройку при обновлении темы.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Этот вариант отключает XML-RPC на уровне WordPress. При обращении к /xmlrpc.php сайт будет отвечать ошибкой, но сам PHP всё равно успеет загрузиться. Для многих проектов этого достаточно.
Вариант 2: блокировка на уровне Nginx
Если вы управляете сервером, лучше отрезать доступ раньше, чем WordPress начнёт обрабатывать запрос. Для Nginx можно добавить отдельное правило:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Такой вариант не даёт запросу дойти до PHP-FPM. Это полезно, если на сайт идёт много мусорного трафика и вы хотите убрать лишнюю нагрузку.
Вариант 3: блокировка на уровне Apache
Если сайт работает на Apache, используйте правило в .htaccess или конфигурации виртуального хоста:
<Files "xmlrpc.php">
Require all denied
</Files>Это тоже жёсткий запрет, но он зависит от того, разрешено ли вам редактировать конфигурацию сервера. На shared-хостинге чаще доступен только .htaccess.
Что выбрать: код, сервер или плагин
Если задача точечная, плагин обычно не нужен. Но иногда удобнее временно проверить эффект через готовый инструмент, а потом перенести настройку в код или серверную конфигурацию. Ниже — короткое сравнение.
| Подход | Плюсы | Минусы | Когда использовать |
|---|---|---|---|
| Фильтр WordPress | Просто внедрить, легко откатить | Запрос доходит до PHP | Если нет доступа к серверу |
| Nginx/Apache | Режет трафик раньше, экономит ресурсы | Нужен доступ к конфигу | Если есть мусорные запросы и нагрузка |
| Плагин | Быстро для теста | Лишняя зависимость | Если нужен временный контроль без кода |
Проверка результата после внедрения
После изменений не ограничивайтесь открытием главной страницы. Проверьте именно тот URL, который вы блокировали. Если XML-RPC отключён корректно, /xmlrpc.php должен перестать отвечать как рабочая точка входа.
Что проверить вручную
- откройте
https://example.com/xmlrpc.phpв браузере; - проверьте ответ через
curl; - посмотрите access log: запросы должны либо исчезнуть, либо получать отказ;
- убедитесь, что обычный вход в админку и публикация записей работают как раньше.
curl -I https://example.com/xmlrpc.phpЕсли блокировка сделана через WordPress-фильтр, вы, скорее всего, увидите HTTP-ошибку или отказ в доступе. Если через сервер — ответ должен приходить без загрузки WordPress, и это легко заметить по логам и времени ответа.
Частые ошибки и как их исправить
Отключили XML-RPC, а потом перестал работать внешний сервис
Значит, сервис действительно использовал XML-RPC, а не REST API. Решение простое: либо вернуть доступ, либо перенастроить интеграцию на современный способ обмена данными. Не держите XML-RPC включённым только из-за одного старого подключения, если его можно заменить.
Добавили код в родительскую тему
После обновления темы настройка исчезнет. Перенесите код в дочернюю тему или в mu-plugin. Для точечных системных ограничений mu-plugin обычно надёжнее: он не зависит от активной темы.
Блокировка через сервер сломала тестовый поддомен
Проверьте, не применили ли вы правило ко всем сайтам на сервере. На мультисайте или при нескольких виртуальных хостах легко случайно закрыть лишний домен. Убедитесь, что правило лежит в нужном server block или в нужном .htaccess.
Ожидали, что исчезнут все атаки
Отключение XML-RPC убирает один вектор, но не заменяет базовую защиту. Если у вас слабые пароли, открытая регистрация или устаревшие плагины, проблемы останутся. XML-RPC — это только один из входов, а не вся безопасность сайта.
Практические советы по безопасности и производительности
Если вы уже занялись XML-RPC, имеет смысл заодно проверить соседние точки риска. Часто вместе с ним оставляют включёнными лишние механизмы, которые тоже создают шум в логах и нагрузку.
- Отключите
wp-jsonтолько если точно понимаете последствия; REST API нужен многим современным плагинам и редактору. - Проверьте, не дублируются ли security-плагины и серверные правила — двойная блокировка иногда мешает диагностике.
- Если у вас есть доступ к WAF или mod_security, добавьте правило для частых атак на
xmlrpc.php, но не полагайтесь только на него. - После изменений очистите кеш страницы и кеш объекта, если он используется, чтобы не смотреть на старые ответы.
Для сайтов, где регулярно приходится чистить лишние запросы, полезно держать под рукой инструменты технической оптимизации вроде Clearfy Pro: он помогает убрать часть дублей и мусорных настроек, но сам по себе не заменяет точечную серверную защиту. Если нужен именно контроль на уровне кода, лучше оставить решение прозрачным и минимальным.
Когда лучше не отключать XML-RPC полностью
Полный запрет не всегда уместен. Если сайт живёт за счёт внешних публикаций, автоматизации или старых интеграций, сначала составьте список клиентов и сервисов, которые реально используют этот канал. В таких проектах разумнее ограничить доступ на уровне IP, поставить дополнительную защиту или перевести интеграции на REST API, а уже потом закрывать XML-RPC окончательно.
Если же никаких зависимостей нет, самый практичный вариант — отключить XML-RPC на уровне WordPress, проверить логи и, при необходимости, усилить блокировку на сервере. Это короткая настройка, но она заметно упрощает жизнь на сайтах, которые регулярно ловят мусорный трафик.