Зачем прятать вход Remnawave за whitelisted CDN
Схема «remnawave за cdn» решает конкретную инфраструктурную проблему. При блокировках и локальных шатдаунах российские мобильные операторы переводят интернет в режим белого списка: абоненту доступны только whitelisted-ресурсы — часть CDN, госсайты, платёжные сервисы. Всё остальное, включая VLESS-ноду, к которой клиент идёт напрямую по IP, просто не отвечает. Для оператора VPN это значит, что в самый нужный момент сервис отваливается у части аудитории.
Подход remnawave whitelist меняет картину. Вход ноды прячется за whitelisted CDN-edge (например, на инфраструктуре Yandex CDN). С точки зрения мобильного оператора абонент обращается к «белому» CDN-домену, а edge уже проксирует трафик на ваш origin — ноду Remnawave. Сама нода при этом остаётся обычным сервером с XHTTP-инбаундом; меняется только маршрут входящего подключения и клиентский конфиг.
Важно сразу разделить две разные задачи. Whitelist-CDN помогает пробить троттлинг и режим белого списка — то есть сохранить связность сервиса под ограничениями оператора. Это не про разблокировку стриминга: Kinopoisk и подобные сервисы банят датацентр-IP по репутации, и здесь нужен резидентный IP, а не CDN-вход. Не путайте эти сценарии — CDN-слой решает только первый.
Транспорт: что реально проходит через edge
Не всякий протокол доживает до origin через CDN. Edge — это HTTP(S)-прокси, и он пропускает только то, что укладывается в обычные веб-запросы. Отсюда жёсткое ограничение по транспорту.
| Транспорт | Через whitelist-CDN | Комментарий |
|---|---|---|
| XHTTP (mode packet-up) | Работает | Основной рабочий вариант: мультиплекс поверх HTTP-запросов, edge его переносит |
| Reality | Обычно не проходит | Требует прямого TLS-хендшейка к ноде, edge его не пропускает |
| Hysteria2 | Обычно не проходит | UDP/QUIC-транспорт, CDN-edge его не проксирует на origin |
Практический вывод: для remnawave за cdn нода держит именно XHTTP-инбаунд (например, на порту 25454), а Reality/Hysteria2 остаются для прямых подключений там, где сеть не в режиме белого списка. Многие операторы держат оба входа параллельно и раздают клиенту профиль с несколькими конфигами, где CDN-вариант — резервный на случай ограничений.
Whitelisted-подсеть: выбор хостера под ноду
Whitelist на мобильных сетях привязан не к домену, а к подсетям /24. У одного хостера подсеть может быть в белых списках, у соседней /24 того же хостера — уже нет. Статус со временем меняется: подсеть, работавшая месяц назад, может выпасть. Поэтому единственно верное правило — проверять каждую /24 актуально, перед запуском и периодически.
| Хостер | Наблюдаемый статус | Замечание |
|---|---|---|
| Selectel | Часто whitelisted | Но проверяйте конкретную /24, а не хостера целиком |
| cloud.ru / SberCloud | Часто НЕ whitelisted | Регулярно вне белых списков |
Это ориентиры, а не гарантии. Гарантированного «белого» хостера не существует: whitelist формируется на стороне операторов и вами не контролируется. Если вы поднимаете origin самостоятельно, закладывайте проверку подсети в чек-лист развёртывания и держите запасную площадку.
Чтобы не проверять /24 вручную и не переезжать при каждом изменении статуса, часть операторов берёт whitelisted-вход как сервис. Clearway (clear-way.pro) даёт именно такой «белый» edge перед вашей нодой на домене *.whitechannel-x1-cdn.ru, не продавая при этом серверов — origin остаётся вашим.
Критичный нюанс XHTTP через CDN: тело вместо заголовка
Это самый неочевидный момент, на котором ломается большинство первых настроек. XHTTP умеет размещать uplink-данные (то, что клиент отправляет на сервер) по-разному, и по умолчанию конфигурации часто кладут их в кастомный заголовок вроде X-Payload. Напрямую нода-клиент это работает. Через CDN — нет.
Причина в том, что CDN-edge не обязан доносить произвольные кастомные заголовки до origin: он их отбрасывает или переписывает. В результате сервер не получает uplink, и туннель рвётся с характерной ошибкой unexpected EOF. Симптом коварный: downlink может идти, страница «почти открывается», но соединение нестабильно и падает.
Правильная раскладка полей XHTTP для работы за CDN:
- uplinkDataPlacement: "body" — данные идут в теле запроса, которое edge обязан передать на origin. Это ключевая настройка.
- session / seq — в cookie: служебные идентификаторы сессии переносим в куки, их edge сохраняет.
- padding — в query: паддинг кладём в query-строку URL.
Есть и приятный побочный эффект. XHTTP плодит много мелких запросов, а CDN тарифицирует не только гигабайты, но и число запросов. Складывая uplink в тело и укрупняя посты, вы снижаете количество запросов — а с ним и стоимость трафика.
Клиентский конфиг и точное совпадение параметров
За CDN нода и клиент должны быть согласованы по параметрам маршрута буква в букву. Любое расхождение — и туннель не поднимется, даже если сам edge всё пропускает.
Что указывает клиент при схеме за CDN:
- Address / SNI / Host — CDN-поддомен (ваш edge-домен), а не IP ноды.
- path — ровно тот же путь, что настроен в XHTTP-инбаунде ноды.
- extra / поля XHTTP — те же значения (включая раскладку uplink в body, cookie, query), что и на сервере.
Правило простое: path и extra на клиенте и на ноде должны совпадать точь-в-точь. Лишний слэш, другой регистр или отличающийся параметр — и вы получите либо unexpected EOF, либо молчаливый отказ соединения. Remnawave генерирует клиентские подписки централизованно, поэтому проще всего задать эти поля один раз в шаблоне инбаунда и раздавать их всем клиентам через панель, а не править руками.
Защита origin и учёт трафика в Remnawave
Спрятав ноду за CDN, вы не должны оставлять её открытой напрямую — иначе весь смысл маскировки теряется, а origin светится в интернет.
Защита origin:
- Закройте firewall'ом входящие подключения к XHTTP-порту так, чтобы принимался трафик только с IP gateway/edge, а не отовсюду.
- Добавьте секрет-заголовок
X-Cdn-Auth: edge проставляет его, origin проверяет и отбрасывает всё, что пришло мимо CDN. Это защищает ноду от прямых обращений и сканеров.
Учёт трафика (механизмы Remnawave):
Remnawave считает потребление на уровне панели, и здесь работают два механизма — множитель потребления ноды и per-user лимиты. Множитель определяет, с каким коэффициентом трафик ноды списывается против лимита пользователя. Установив на CDN-ноде множитель 0, вы делаете так, что трафик через неё не засчитывается против лимита юзера, хотя нода полностью работает. Это удобно, если CDN-вход — резервный канал для моментов ограничений и вы не хотите наказывать абонента за вынужденное переключение. Per-user лимиты при этом продолжают действовать на остальных нодах в обычном режиме.
Прайс за гигабайт — только половина счёта. Вторая половина у части провайдеров это запросы, а XHTTP в режиме packet-up дробит аплинк на множество мелких обращений. Аккуратная раскладка uplink в body (см. выше) прямо влияет на эту цифру.