Что такое троттлинг и режим «белого списка»
В обиходе троттлингом называют любое замедление интернета оператором, но для VPN-инфраструктуры важно различать три разных режима:
- Замедление (throttling) — оператор режет скорость до определённых ресурсов или протоколов, соединение живёт, но деградирует.
- Shutdown мобильного интернета — полное отключение передачи данных в регионе или на площадке; не работает ничего, кроме голоса и SMS.
- Режим «белого списка» (whitelist) — промежуточный и самый частый на практике: мобильный интернет формально включён, но пропускает только whitelisted-ресурсы. Это часть CDN, госсайты, отдельные сервисы; всё остальное таймаутит.
Именно последний режим ломает VPN-сервисы неочевидным образом. Для конечного пользователя это выглядит как «интернет вроде есть, но ничего не грузится, кроме Госуслуг». Для оператора VPN это означает, что прямой путь клиента до ноды перестаёт существовать, хотя канал технически поднят.
Почему обычный VPN отваливается под троттлингом
VPN-нода живёт на IP датацентра. В режиме белого списка мобильный оператор пропускает трафик только к подсетям из своего whitelist, а подсеть датацентра туда, как правило, не входит. Клиент шлёт первый пакет на ноду — и не получает ответа. Симптом со стороны пользователя: подписка активна, конфиг валиден, но туннель не поднимается или рвётся сразу после хендшейка.
Отдельно страдают «прямые» обфусцированные транспорты. Reality и Hysteria2, направленные напрямую на ноду, под троттлингом обычно не проходят: пограничный узел оператора просто не пропускает соединение к неразрешённому адресу, и вся маскировка под TLS уже не имеет значения — трафик не доходит до точки, где её можно было бы применить.
Вывод для оператора: устойчивость сервиса под ограничениями оператора связи — это в первую очередь вопрос адреса назначения, а уже потом транспорта и обфускации. Нужно, чтобы первый байт клиента уходил на адрес, который оператор считает «белым».
Нужен вход, который проходит при белых списках, прямо сейчас? CLEAR VPN: первые 5 дней бесплатно, карта не нужна, до 10 устройств.
Получить ключ на 5 дней →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-адрес, а туннель терминируется уже на вашей ноде.
Актуальные настройки XHTTP через CDN
Это самый неочевидный, но решающий момент при заводе XHTTP через CDN. Если туннель поднимается на прямом соединении, но рвётся именно через CDN с ошибкой unexpected EOF — почти всегда дело в том, куда положены uplink-данные.
Ошибка 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 нельзя переносить в клиентскую ссылку.
Правила, которые нужно соблюсти:
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.
Панели, безопасность 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 на ноде означает, что трафик через неё не засчитывается против лимита пользователя (при этом сама нода работает штатно) — удобно для служебных или дотационных маршрутов.
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.
Чего whitelist-CDN не решает
Важно не путать две разные задачи. Спрятать вход за whitelisted CDN — это про устойчивость соединения под троттлингом оператора. Это не про разблокировку стриминга.
Сервисы вроде Kinopoisk банят IP датацентров по репутации: для доступа к российскому контенту нужен резидентный IP, а whitelist-CDN этого не даёт — трафик всё равно приходит с датацентрового адреса edge/origin. Это отдельная инженерная задача, которую нельзя закрыть той же схемой.
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.