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