Зачем ставить Marzban за whitelisted-CDN
При блокировках и локальных шатдаунах мобильные операторы в РФ переводят интернет в режим белого списка: доступны только whitelisted-ресурсы — часть CDN, госсайты, платёжные шлюзы. VPN, который идёт напрямую к своей ноде по датацентровому IP, в этот момент просто отваливается — пакеты до origin не доходят.
Решение на уровне инфраструктуры — спрятать вход ноды за whitelisted CDN-edge. Оператор видит трафик как обращение к «белому» CDN (например, Yandex CDN), edge принимает запрос и проксирует его на вашу ноду. Для схемы marzban cdn это означает, что панель держит XHTTP-инбаунд на origin, а клиенты в конфиге указывают не IP ноды, а CDN-поддомен.
Важная деталь: whitelist привязан не к домену, а к подсетям /24. У одних точек входа подсети попадают в белые списки, у других — нет, и статус меняется. Поэтому «Marzban за CDN» — это не разовая настройка, а связка «правильный edge + правильный транспорт + актуально проверенная /24».
Почему XHTTP, а не Reality или Hysteria2
Под троттлингом и в режиме белого списка edge пропускает то, что выглядит как обычный HTTPS-трафик к CDN. Поэтому выбор транспорта здесь не косметический:
- XHTTP (mode packet-up) через CDN — рабочий подход. Туннель выглядит как серия HTTP-запросов к CDN-поддомену, edge их спокойно проксирует на origin.
- Reality напрямую под троттлингом обычно не проходит: это не CDN-совместимый транспорт, edge его до origin не доносит.
- Hysteria2 (QUIC/UDP) через HTTP-CDN не живёт — edge заточен под HTTP, а не под произвольный UDP.
Отсюда практический вывод: для схемы за CDN берём именно marzban xhttp, а Reality/Hysteria2 оставляем для прямых подключений там, где сеть не в режиме белого списка.
Ключевая деталь: uplink в теле запроса
Это самый неочевидный момент, на котором рвётся большинство первых попыток. XHTTP умеет размещать uplink-данные (то, что клиент отправляет наверх) двумя способами: в теле запроса или в кастомном заголовке (например, X-Payload). Напрямую, без CDN, работают оба. Через CDN — только тело.
Причина в том, что CDN-edge не обязан доносить произвольные кастомные заголовки до origin: он их режет или переписывает. Если uplink уедет в заголовок, до ноды он не дойдёт, и туннель порвётся — характерный симптом «unexpected EOF» в логах Xray.
Поэтому на XHTTP-инбаунде обязательно:
uplinkDataPlacement: "body"— данные идут в теле запроса;- session/seq — в cookie (их CDN передаёт корректно);
- padding — в query-строке.
Побочный плюс: крупные POST-запросы в теле уменьшают число мелких запросов, а значит и стоимость — CDN часто тарифицирует ещё и per-request.
Настройка XHTTP-инбаунда в Marzban
Marzban работает на ядре Xray-core, поэтому XHTTP-инбаунд добавляется в его xray-конфиг. Убедитесь, что стоит актуальная версия ядра с поддержкой XHTTP.
Ориентиры по инбаунду:
- отдельный порт под XHTTP на origin, например
25454; network: xhttp,mode: packet-up;- уникальный секретный
path(не/, не угадываемый); host— ваш CDN-поддомен;- блок
extraсuplinkDataPlacement: "body"и размещением session/seq/padding, как описано выше.
TLS в схеме за CDN обычно терминируется на edge: клиент идёт к CDN по 443/TLS, а edge → origin ходит по внутренней схеме (plain или собственный TLS ноды). Главное — чтобы транспортные параметры совпадали по всей цепочке.
Клиентский конфиг и совпадение параметров
На стороне клиента конфиг указывает не адрес ноды, а CDN-поддомен как Address / SNI / Host. Любое расхождение path или extra между нодой и клиентом — и туннель не поднимется. Сверяйте параметры буквально.
| Параметр | На ноде (Marzban inbound) | В клиентском конфиге |
|---|---|---|
| Address / SNI / Host | слушает origin | CDN-поддомен (*.whitechannel-x1-cdn.ru) |
| Network / транспорт | xhttp | xhttp |
| Mode | packet-up | packet-up |
| Path | /uniq-secret | /uniq-secret (точь-в-точь) |
| uplinkDataPlacement | body | body |
| Порт | 25454 (origin) | 443 (порт CDN) |
Ключевое правило: path и все extra-параметры на ноде и на клиенте должны совпадать точь-в-точь, включая регистр и слеши. Порт в клиенте — это порт CDN (443), а не 25454 ноды: до порта origin клиент вообще не обращается.
Защита origin, учёт трафика и экономика
Раз вход публичный только через CDN, origin надо закрыть от прямых обращений:
- файрвол на вход — только с IP gateway/edge, всё остальное drop;
- секрет-заголовок
X-Cdn-Auth: edge добавляет его к запросам, origin отклоняет всё без него. Так ноду не найдут прямым сканом по IP.
Учёт трафика. Marzban считает потребление по пользователям и применяет per-user лимиты — это не меняется от того, что вход за CDN. Но появляется вторая статья расходов: сам CDN-трафик. Номинальная цена за гигабайт мало что говорит: у провайдеров с тарификацией запросов XHTTP-профиль добавляет к счёту отдельную статью, и реальная ставка получается заметно выше прайсовой. Отсюда практическая мотивация держать uplink в теле и укрупнять посты: меньше запросов — ниже счёт.
Собрать всё это самому — свой edge, whitelisted-подсети, мониторинг статуса /24 — можно, но это отдельная инженерная задача. Clearway даёт whitelisted-вход как сервис: оператор подключает свою ноду Marzban к готовому CDN-edge (домен вида *.whitechannel-x1-cdn.ru), не покупая и не поддерживая серверы edge самостоятельно.