Зачем прятать вход 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-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Причина в том, что CDN-edge не обязан доносить произвольные кастомные заголовки до origin: он их отбрасывает или переписывает. В результате сервер не получает uplink, и туннель рвётся с характерной ошибкой unexpected EOF. Симптом коварный: downlink может идти, страница «почти открывается», но соединение нестабильно и падает.
Правильная раскладка полей XHTTP для работы за CDN:
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.
Клиентский конфиг и точное совпадение параметров
За CDN нода и клиент должны быть согласованы по параметрам маршрута буква в букву. Любое расхождение — и туннель не поднимется, даже если сам edge всё пропускает.
Что указывает клиент при схеме за CDN:
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Ошибка unexpected EOF сама по себе не определяет причину. В текущем входе Clearway GET с телом отклоняется CDN с ошибкой 413. Проверьте серверный auto и лимит заголовков, затем клиентский header; для других ошибок сопоставьте время и журналы клиента, CDN, gateway и origin. Ответ HTTP 200 и успешный TLS ещё не подтверждают передачу HTTPS через туннель. Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Защита 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 лимиты при этом продолжают действовать на остальных нодах в обычном режиме.
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.