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