Что значит «белый список» на Tele2 при блокировках
Когда речь заходит про запрос «теле2 блокировка», важно разделять два режима. В обычном состоянии оператор просто фильтрует отдельные протоколы и адреса — тут ещё выживают многие транспорты. Но при жёстких ограничениях или локальном шатдауне мобильный интернет может переходить в режим белого списка: сеть пропускает трафик только к заранее одобренным ресурсам — части CDN, госсервисам, платёжным системам, — а всё остальное просто не устанавливает соединение.
Для VPN-сервиса это критично. Нода, к которой клиент обращается напрямую по её датацентр-IP, в белый список не входит. Результат — туннель не поднимается вообще, независимо от протокола. Отсюда и практический вывос для оператора: устойчивость сервиса под ограничениями Tele2 определяется не «крутостью» протокола, а тем, через какой вход клиент достаёт вашу ноду.
Почему Reality и Hysteria2 напрямую падают, а XHTTP через CDN держится
Под троттлингом и в режиме белого списка транспорты, которые ходят прямо на IP ноды, обычно не проходят: edge оператора их не пропускает. Это касается и Reality, и Hysteria2 — сам по себе протокол не делает адрес назначения «белым».
Рабочий подход — спрятать вход за whitelisted CDN-edge (например, крупный CDN, чьи подсети уже в белых списках). Клиент обращается к домену CDN, оператор видит обычное обращение к «белому» ресурсу, а CDN проксирует запрос на вашу ноду (origin). Транспортом здесь выступает XHTTP в режиме packet-up — он ложится на обычный HTTP-профиль, который CDN штатно прокидывает. Это и есть техническая суть связки «vpn tele2 + tele2 белый список»: вы не пробиваете фильтр в лоб, а входите через ресурс, который у оператора уже разрешён.
Whitelist привязан к подсетям /24 — проверяйте каждую
Ключевая тонкость: белый список привязан не к «CDN вообще», а к конкретным подсетям /24. У одного хостера подсети попадают в белые списки, у другого — нет, и статус со временем меняется. Поэтому единственно честный ответ — «проверяйте актуально», без гарантий.
| Хостер / источник IP | Типичный статус whitelist | Комментарий |
|---|---|---|
| Selectel | Часто whitelisted | Нередко проходит, но проверять каждую /24 |
| cloud.ru / SberCloud | Часто НЕ whitelisted | Обычно не годится как edge под троттлингом |
| Датацентр-IP ноды напрямую | Нет | Всегда отваливается в режиме белого списка |
Таблица — ориентир, а не гарантия. Перед прод-запуском проверяйте статус конкретной /24 из реальной сети Tele2 в нужном регионе, потому что распределение белых подсетей неоднородно и обновляется.
Настройка XHTTP через CDN: неочевидный, но решающий момент
Здесь чаще всего ломаются даже опытные операторы. При проксировании XHTTP через CDN uplink-данные обязаны идти в теле запроса — uplinkDataPlacement: "body", а не в кастомном заголовке (например, X-Payload). Причина простая: CDN-edge кастомные заголовки до origin не доносит, поэтому uplink теряется и туннель рвётся с характерным unexpected EOF.
Практические правила связки:
- Uplink — в body. Session/seq кладите в cookie, padding — в query. Так всё, что нужно туннелю, переживает проход через edge.
- Path и extra должны совпадать точь-в-точь на клиенте и на ноде. Любое расхождение — туннель не поднимается.
- Нода держит XHTTP-инбаунд на своём порту (например,
25454); клиентский конфиг указывает CDN-поддомен как Address/SNI/Host. - Подходят Remnawave, 3x-ui, Marzban, Hiddify — механика одинакова, отличается только UI.
Отдельно про экономику: крупные POST'ы в body снижают число мелких запросов, а значит и стоимость.
Себестоимость трафика и учёт потребления
На масштабе плата за запросы становится отдельной статьёй расхода, и считать её надо по своей выгрузке из биллинга, а не по прайсу. Снижают её укрупнением полезной нагрузки (крупные посты в body уменьшают число обращений к edge).
Учёт на стороне панели — отдельный слой. В Remnawave есть множитель потребления ноды и per-user лимиты. Множитель 0 на ноде означает, что трафик через неё не считается против лимита пользователя, при этом сама нода работает штатно — удобно для fallback-входа, который вы не хотите тарифицировать. Эти механизмы позволяют держать CDN-вход как резервный канал именно под сценарии белого списка, не ломая биллинг основного трафика.
Безопасность origin и границы метода
Если вы прячете ноду за CDN, origin нужно закрыть. Файрволом разрешайте входящие соединения только с IP gateway, а от прямых обращений мимо CDN защищайтесь секрет-заголовком X-Cdn-Auth, который edge проставляет, а origin проверяет. Иначе датацентр-IP ноды быстро найдут и заблокируют напрямую.
Важно не путать две задачи. Whitelisted CDN-вход решает проблему троттлинга и белого списка — он даёт «белый» вход перед нодой. Но он не разблокирует стриминг: тот же Kinopoisk банит датацентр-IP по репутации, и для российского контента нужен резидентный IP — это отдельная инженерная задача.
Поднимать и сопровождать собственный пул whitelisted-подсетей — трудоёмко: их надо находить, мониторить и заменять по мере выпадения из белых списков. Поэтому часть операторов берёт whitelisted-вход как сервис. Именно это делает Clearway (clear-way.pro): даёт VPN-операторам «белый» CDN-вход перед их нодами по модели whitelist-CDN как сервис, без продажи серверов — вы держите свою инфраструктуру, а входной слой получаете готовым.