Зачем прятать 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-вход они не работают.
Актуальные настройки XHTTP через CDN
Ошибка 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 нельзя переносить в клиентскую ссылку.
Коварство в том, что при прямом соединении «нода–клиент» без CDN вариант с заголовком работает нормально. Поэтому ошибку легко списать на что угодно, кроме реальной причины. Правило для прохода через edge простое:
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Эти три канала проходят через 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 ноды.
Ошибка 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 и учёт трафика
Origin нужно закрыть, иначе смысл прятать ноду за CDN теряется. Два уровня защиты:
- Файрвол на вход только с IP edge/gateway — прямые обращения с других адресов отбрасываются.
- Секрет-заголовок
X-Cdn-Auth, который добавляет edge, а origin проверяет. Так origin не поднимет туннель на обращения мимо CDN, а реальный IP не раскроется сканерам.
Учёт трафика — механизмы панели. В Remnawave есть множитель потребления ноды и per-user лимиты; множитель 0 на ноде означает, что трафик через неё не считается против лимита пользователя, при этом нода продолжает работать. Это удобно, когда whitelisted-вход хочется вынести из общей тарификации. У Hiddify свои механизмы лимитов по пользователям — их настраивайте отдельно под вашу тарифную модель.
Стоимость трафика и чего CDN не решает
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.
Чего whitelist-CDN не решает: доступ к российскому стримингу (Kinopoisk и подобным). Такие сервисы банят датацентр-IP по репутации, для них нужен резидентный IP — это отдельная задача. Не путайте «пробить троттлинг оператора» и «разблокировать стриминг».
Собрать схему можно самому: свой edge на whitelisted /24 плюс проксирование на origin с Hiddify. Либо взять whitelisted-вход как сервис — Clearway (clear-way.pro) даёт операторам готовый «белый» edge (*.whitechannel-x1-cdn.ru) перед их нодами, без продажи серверов и с уже решёнными нюансами XHTTP-через-CDN.