XML-RPC в WordPress часто оставляют включённым «на всякий случай», а потом удивляются лишним запросам, шуму в логах и попыткам брутфорса через xmlrpc.php. Полностью рубить доступ не всегда правильно: у части сайтов ещё живы внешние публикации, мобильные клиенты и старые интеграции. Поэтому задача обычно не в том, чтобы просто выключить файл, а в том, чтобы сначала понять, кто и зачем его вызывает, а потом убрать лишнее без побочных эффектов.
Когда XML-RPC действительно мешает
Проблема заметна не всегда в интерфейсе WordPress, а на уровне сервера и безопасности. Типичные симптомы:
- в access log регулярно появляются запросы к
/xmlrpc.php; - в логах безопасности видны серии POST-запросов с одинаковым шаблоном;
- на слабом хостинге растёт нагрузка из-за массовых попыток авторизации;
- часть внешних сервисов перестаёт публиковать записи, если XML-RPC отключили слишком рано.
Если сайт не использует Jetpack, старые мобильные приложения WordPress и сторонние сервисы публикации, XML-RPC обычно можно отключить. Но перед этим лучше проверить, нет ли реальной зависимости.
Диагностика: кто обращается к xmlrpc.php
Сначала смотрим не на догадки, а на факты. Если есть доступ к логам веб-сервера, найдите обращения к xmlrpc.php за последние дни. На Nginx это можно сделать через grep, на Apache — по access log.
grep "xmlrpc.php" /var/log/nginx/access.log | tail -n 50Если запросов много и они идут с разных IP, это часто автоматический перебор. Если запросы редкие, но идут с одного адреса, проверьте, не ваш ли это сервис: резервное копирование, публикация через API, мобильный клиент, мониторинг.
Что проверить в админке и интеграциях
- используется ли Jetpack;
- есть ли внешние сервисы автопостинга;
- подключены ли старые мобильные приложения WordPress;
- есть ли сторонние плагины, которые явно упоминают XML-RPC в документации;
- не настроена ли синхронизация через устаревший клиент.
Если ничего из этого не используется, можно переходить к отключению. Если зависимость есть, лучше не блокировать файл целиком, а ограничить доступ на уровне сервера или WAF.
Варианты решения: что выбрать на практике
| Подход | Когда подходит | Минус |
|---|---|---|
| Отключить через код | XML-RPC не нужен вообще | Нужно помнить про исключения для интеграций |
| Закрыть на уровне Nginx/Apache | Нужна защита до загрузки WordPress | Сложнее сопровождать на разных хостингах |
| Оставить, но ограничить правилами безопасности | Есть рабочие интеграции | Не убирает сам факт доступности файла |
Для большинства сайтов без интеграций достаточно отключения через functions.php или mu-plugin. Если нужен более жёсткий контроль, добавьте серверное правило.
Пошаговое решение через код
Самый предсказуемый способ — запретить саму возможность использования XML-RPC на уровне WordPress. Это не ломает сайт целиком и легко откатывается.
<?php
add_filter( 'xmlrpc_enabled', '__return_false' );Такой вариант отключает XML-RPC для WordPress, но файл xmlrpc.php физически остаётся доступным. Если цель — ещё и снизить шум от сканеров, лучше дополнить это серверной блокировкой.
Блокировка на уровне Nginx
Если у вас Nginx, можно вернуть 403 для прямых обращений к файлу. Это полезно, когда боты долбят именно в xmlrpc.php, а не в WordPress-логику.
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}После изменения конфигурации проверьте синтаксис и перезагрузите сервер. На практике это лучше делать только после того, как вы убедились, что XML-RPC не нужен ни одному сервису.
Если нужен частичный доступ
Иногда полный запрет не подходит. Тогда можно оставить XML-RPC включённым, но закрыть его на уровне WAF, fail2ban или правил безопасности хостинга. Это не идеальная замена, но в реальных проектах часто помогает убрать массовые попытки авторизации без риска сломать интеграцию.
Проверка результата после внедрения
После отключения не ограничивайтесь тем, что страница сайта открывается. Нужно проверить именно поведение xmlrpc.php и связанные сценарии.
- Откройте
/xmlrpc.phpв браузере или черезcurl— ответ не должен быть обычным рабочим XML-RPC-эндпоинтом. - Проверьте логи сервера: новые обращения должны либо исчезнуть, либо получать 403/405.
- Если у вас был внешний сервис публикации, сделайте тестовую отправку записи.
- Проверьте, не появились ли ошибки в логах плагинов интеграции.
Для быстрой проверки через консоль можно использовать такой запрос:
curl -I https://example.com/xmlrpc.phpЕсли вы видите 403 Forbidden или другой запретительный ответ, блокировка сработала. Если приходит обычный ответ WordPress, значит правило не применилось или было добавлено не в тот слой.
Частые ошибки и как их исправить
Отключили XML-RPC, не проверив интеграции
Это самая неприятная ошибка. Сайт продолжает работать, но внешняя публикация или синхронизация внезапно перестаёт отправлять контент. Исправление простое: временно верните фильтр, проверьте список подключений и отключайте только после теста.
Добавили правило не туда
На Nginx правило в .htaccess не сработает, а на Apache директива Nginx, конечно, тоже бесполезна. Сначала определите стек, потом вносите изменение. Если доступ к конфигу сервера ограничен, используйте фильтр WordPress.
Спрятали проблему, но не убрали нагрузку
Иногда XML-RPC не нужен, но его продолжают атаковать. Если ограничиться только фильтром, боты всё равно будут стучаться в файл. В таком случае добавьте блокировку на сервере или через защитный модуль хостинга.
Проверили только главную страницу
Это не подтверждает, что XML-RPC отключён. Нужна проверка именно конечной точки /xmlrpc.php и логов после изменения.
Безопасность и производительность: что имеет смысл сделать рядом
Если вы уже чистите поверхность атаки, имеет смысл посмотреть и на соседние точки входа. На сайтах с лишними запросами обычно полезно:
- ограничить попытки входа в админку;
- проверить, не открыт ли REST API там, где он не нужен внешним сервисам;
- убрать устаревшие интеграции, которые давно не используются;
- проверить, не создают ли плагины лишние фоновые запросы.
Для сайтов, где важна именно техническая чистка и снижение дублей, иногда удобнее закрывать такие вещи через набор правил в одном месте. Если нужен инструментальный подход, у WPShop есть Clearfy Pro: он помогает централизованно отключать часть лишнего функционала и чистить сайт без ручного разбрасывания по теме и плагинам. Ссылку лучше проверять по задаче, а не ставить всё подряд: Clearfy Pro.
Главная идея простая: XML-RPC не нужно отключать «на веру». Сначала смотрим, кто его использует, потом выбираем уровень блокировки, потом проверяем логи и реальные интеграции. Тогда решение не превращается в случайную поломку рабочего сайта.