XML-RPC в WordPress часто отключают «на всякий случай», а потом внезапно перестают работать мобильное приложение, публикация через внешние сервисы или удалённая интеграция с сайтом. Проблема в том, что этот интерфейс нужен не всем, но если он используется, выключать его вслепую нельзя.
Ниже — практический сценарий: как понять, нужен ли xmlrpc.php именно вашему сайту, как отключить его безопасно и как проверить, что ничего не сломалось.
Когда XML-RPC действительно стоит отключать
Если вы не используете старые внешние клиенты, публикацию по API из сторонних сервисов или синхронизацию через XML-RPC, этот файл чаще всего только расширяет поверхность атаки. Через него пытаются подбирать пароли, запускать массовые запросы и проверять доступность сайта.
Но есть и обратная сторона: некоторые плагины, мобильные приложения WordPress и интеграции с сервисами публикации до сих пор используют XML-RPC. Поэтому сначала нужно проверить фактическое использование, а не ориентироваться на общую рекомендацию из статьи.
Быстрая диагностика: нужен ли вам xmlrpc.php
Проверьте, есть ли в работе сайта хотя бы один из таких сценариев:
- публикация или редактирование записей через сторонний клиент;
- мобильное приложение WordPress для администрирования;
- интеграции, которые отправляют записи через XML-RPC, а не REST API;
- старые плагины синхронизации, резервного копирования или автопостинга;
- внешние сервисы, где в настройках явно указан XML-RPC endpoint.
Если ничего из этого нет, отключение обычно безопасно. Если есть сомнения, сначала проверьте логи веб-сервера и список подключённых сервисов.
Как проверить, используется ли XML-RPC сейчас
Самый надёжный способ — посмотреть, обращается ли кто-то к /xmlrpc.php. Это можно сделать на уровне логов или простым тестом снаружи.
Проверка через curl
Запрос к файлу должен вернуть не страницу 404, а ответ WordPress или сообщение о недоступности метода. Если после отключения вы видите 403 или 404, это ожидаемо. До отключения можно проверить доступность так:
curl -I https://example.com/xmlrpc.phpЕсли сервер отвечает 200 OK или 405 Method Not Allowed, файл доступен. Это ещё не значит, что его кто-то использует, но значит, что он открыт для запросов.
Проверка по логам
Ищите обращения к xmlrpc.php в access.log. Если запросы идут регулярно и с разных IP, это повод не рубить доступ без анализа. Если это только сканеры и боты, отключение обычно оправдано.
grep "xmlrpc.php" /var/log/nginx/access.logНа shared-хостинге можно посмотреть журналы в панели управления или попросить поддержку выгрузить фрагмент логов.
Пошаговое отключение XML-RPC
Есть три рабочих подхода: через плагин, через код и через веб-сервер. Выбор зависит от того, насколько у вас управляемая среда.
| Способ | Когда подходит | Плюс | Минус |
|---|---|---|---|
| Плагин безопасности | Если не хотите править код | Быстро и без деплоя | Добавляет ещё один слой логики |
| Код в теме или mu-plugin | Если нужен контроль в проекте | Прозрачно и предсказуемо | Нужно не забыть при переносе |
| Правило на уровне nginx/Apache | Если есть доступ к серверу | Отсекает запросы раньше WordPress | Требует доступа к конфигу |
Вариант 1: отключить через код
Если вы ведёте проект аккуратно, лучше добавить небольшой mu-plugin. Так правило не потеряется при смене темы.
<?php
/**
* Plugin Name: Disable XML-RPC
*/
add_filter( 'xmlrpc_enabled', '__return_false' );Файл можно положить в wp-content/mu-plugins/disable-xmlrpc.php. Если каталога mu-plugins нет, создайте его вручную.
Вариант 2: закрыть доступ на уровне nginx
Если сервер под вашим контролем, можно отрезать запросы к файлу ещё до загрузки WordPress:
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}Это хороший вариант для сайтов, где XML-RPC точно не нужен. Для Apache логика будет другой, но смысл тот же: не отдавать файл наружу.
Вариант 3: использовать плагин
Если проект не ваш по инфраструктуре или нет доступа к конфигам, можно отключить XML-RPC через плагин безопасности. Важно только не ставить несколько плагинов, которые делают одно и то же: потом сложно понять, что именно блокирует доступ.
Если у вас уже стоит плагин для чистки и SEO-оптимизации вроде Clearfy Pro, проверьте, не включена ли там отдельная настройка для XML-RPC. В таком случае не дублируйте блокировку кодом и серверным правилом одновременно без необходимости.
Что сломается после отключения и как это заметить
После внедрения проверьте не только главную страницу, но и все сценарии, которые потенциально завязаны на удалённый доступ. Ошибка здесь обычно проявляется не сразу: сайт открывается, но публикация из внешнего сервиса уже не проходит.
- откройте
/xmlrpc.phpв браузере или черезcurl; - проверьте мобильное приложение WordPress, если оно используется;
- сделайте тестовую публикацию из внешнего сервиса;
- посмотрите журнал ошибок и access.log на предмет повторяющихся запросов;
- убедитесь, что REST API работает, если интеграции переведены на него.
Если после отключения внешний сервис перестал публиковать записи, значит он действительно использовал XML-RPC. В этом случае нужно либо вернуть доступ, либо перенастроить интеграцию на REST API, если сервис это поддерживает.
Частые ошибки и как их исправить
Отключили XML-RPC, но забыли про зависимый сервис
Это самая частая ситуация. Сайт при этом выглядит нормально, но автопостинг, синхронизация или мобильный клиент перестают работать. Решение простое: сначала найти зависимость, потом отключать.
Поставили сразу три способа блокировки
Когда XML-RPC закрыт и в плагине, и в коде, и в конфиге сервера, диагностика превращается в угадайку. Если что-то сломалось, вы не поймёте, где именно сработало ограничение. Лучше оставить один основной способ и один резервный, если это действительно нужно.
Перепутали XML-RPC и REST API
Это разные механизмы. Отключение xmlrpc.php не должно ломать REST API, но если у вас одновременно стоят плагины безопасности, проверьте, не режут ли они ещё и /wp-json/. Иногда проблема не в XML-RPC, а в слишком агрессивной защите.
Скрыли проблему, но не убрали причину атак
Если сайт постоянно получает массовые запросы к xmlrpc.php, одной блокировки может быть мало. Проверьте rate limiting, базовую защиту входа в админку, двухфакторную аутентификацию и актуальность плагинов. Иначе боты просто переключатся на другой вектор.
Практические советы по безопасности и производительности
Отключение XML-RPC — это не панацея, а один из слоёв защиты. На практике лучше сочетать его с другими мерами:
- ограничить попытки входа в админку;
- включить двухфакторную аутентификацию для администраторов;
- обновлять ядро, темы и плагины без задержек;
- не держать лишние плагины, которые дублируют одну и ту же функцию;
- проверять, не открыт ли доступ к
xmlrpc.phpпосле миграции или смены хостинга.
Если вы уже используете набор для технической чистки и защиты сайта, имеет смысл держать такие настройки в одном месте, а не размазывать по нескольким плагинам и конфигам. Это упрощает поддержку и снижает риск конфликтов.
Как понять, что решение сработало
После отключения должен быть понятный и воспроизводимый результат. Минимальный набор проверки такой:
- запрос к
/xmlrpc.phpбольше не проходит; - в логах нет новых обращений от легитимных сервисов, которые вы не планировали ломать;
- мобильное приложение и внешние интеграции, если они есть, либо переведены на другой способ доступа, либо подтверждённо не используются;
- REST API и обычная работа сайта не затронуты.
Если все четыре пункта выполняются, XML-RPC можно считать отключённым без побочных эффектов. Если хотя бы один пункт провален, возвращайтесь к диагностике и ищите зависимость до следующего изменения.