Почему прямой VPN отваливается под троттлингом
Когда мобильный оператор в РФ сталкивается с требованием ограничить доступ или проходит через локальный шатдаун, сеть часто переводится не в полный офф, а в режим «белого списка». В этом режиме мобильный интернет пропускает трафик только к whitelisted-ресурсам: части CDN, государственным и инфраструктурным сайтам. Всё остальное — включая прямое TCP/UDP-соединение с вашей VPN-нодой — просто не устанавливается.
Для оператора это выглядит так: сервис работает в обычном режиме, но в момент ограничения все клиенты в затронутом регионе одновременно теряют коннект к ноде. Пинги до IP ноды не проходят, handshake не начинается. Проблема не в конфиге и не в блокировке протокола по DPI — сам маршрут до датацентрового IP закрыт на уровне оператора.
Отсюда вывод, который меняет архитектуру: под троттлингом нельзя ходить напрямую к своему серверу. Клиент должен обращаться к адресу, который оператор считает «белым». Единственный практичный способ получить такой адрес — спрятать вход за whitelisted CDN-edge.
Как whitelist-CDN закрывает вход: архитектура
Идея проста: между клиентом и нодой ставится CDN-edge, чей диапазон адресов попадает в белые списки операторов. Клиент подключается не к IP ноды, а к CDN-поддомену. Для оператора это выглядит как обычное обращение к «белому» CDN; CDN, в свою очередь, проксирует запрос на ваш origin — ноду с VPN-инбаундом.
| Звено | Что видит оператор | Что происходит на самом деле |
|---|---|---|
| Клиент → CDN-edge | Запрос к whitelisted CDN | TLS-сессия к «белому» поддомену |
| CDN-edge → origin | (трафик уже вне моб. сети) | Проксирование на ноду по HTTP(S) |
| origin (нода) | — | XHTTP-инбаунд принимает туннель |
Ключевое свойство схемы: адрес, к которому идёт клиент, и адрес вашей ноды — разные. Нода может стоять на «сером» хостере, который сам по себе не whitelisted, потому что клиент до него напрямую не ходит. Белым должен быть только edge.
Именно этот «белый вход перед нодой» и продаёт Clearway (clear-way.pro) как сервис: оператор получает whitelisted CDN-поддомен (*.whitechannel-x1-cdn.ru) перед своей инфраструктурой, не покупая и не арендуя серверы под CDN.
Транспорт: почему XHTTP (packet-up), а не Reality или Hysteria2
Не любой транспорт переживёт прохождение через CDN. Reality и Hysteria2 напрямую под троттлингом обычно не проходят: Hysteria2 работает поверх QUIC/UDP, который edge либо не проксирует, либо режет, а Reality рассчитан на прямое TLS-соединение с нодой и теряет смысл, когда перед нодой стоит чужой CDN, терминирующий TLS.
XHTTP (наследник SplitHTTP) устроен иначе: он оформляет туннель как последовательность обычных HTTP-запросов. Для CDN это неотличимо от нормального веб-трафика, поэтому edge его прозрачно проксирует. Режим mode: packet-up дополнительно оптимизирует восходящий поток, что важно именно за CDN.
| Транспорт | Через whitelist-CDN | Причина |
|---|---|---|
| VLESS XHTTP (packet-up) | Работает | Выглядит как HTTP-запросы, edge проксирует |
| Reality | Не подходит | Нужен прямой TLS к ноде; CDN терминирует TLS |
| Hysteria2 | Обычно не проходит | QUIC/UDP edge не пропускает |
Поэтому базовая связка для устойчивости под ограничениями — VLESS XHTTP через CDN. Дальше — про настройку и главный подводный камень.
Актуальные настройки 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 нельзя переносить в клиентскую ссылку.
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Пошаговая настройка ноды и клиента
На стороне ноды поднимается XHTTP-инбаунд — например, на порту 25454, слушающий там, куда ходит только CDN. На стороне клиента в качестве Address / SNI / Host указывается CDN-поддомен, а не IP ноды.
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Проверку удобно вести послойно, отсекая слои по одному:
- origin отвечает локально (нода поднята, инбаунд слушает);
- origin отвечает через CDN по HTTP (edge проксирует до ноды);
- поднимается полный туннель с клиента.
Если шаг 1 и 2 проходят, а туннель не встаёт — почти наверняка виноват рассинхрон path/extra или uplink в заголовке (см. предыдущую секцию).
Whitelist живёт на уровне /24: выбор хостера и подсети
Белые списки операторов привязаны не к домену CDN и не к ASN, а к подсетям — как правило, к блокам /24. Значит, «whitelisted» — свойство конкретного диапазона IP edge, а не бренда CDN целиком. У одного провайдера часть /24 в белых списках, часть — нет; статус со временем меняется.
Из практики распределение примерно такое (но проверять нужно всегда актуально и по каждой /24 отдельно):
| Хостер / провайдер | Часто whitelisted |
|---|---|
| Selectel | Да, встречается часто |
| cloud.ru / SberCloud | Часто нет |
Гарантий здесь нет и быть не может: сегодня /24 проходит, завтра выпадает. Поэтому выбор edge — не разовое решение, а постоянный мониторинг статуса подсетей. Оператору, который не хочет держать это на себе, проще брать whitelisted-вход как сервис: Clearway как раз закрывает подбор и поддержание «белых» edge-подсетей, отдавая оператору стабильный поддомен перед его нодами.
Безопасность origin: закрыть ноду от прямых обращений
Как только вход спрятан за CDN, origin нужно защитить от обращений мимо CDN — иначе ноду легко найти сканером, и смысл «спрятанного» входа теряется.
Два уровня защиты:
- Firewall на вход. Разрешить входящие только с IP gateway/CDN-edge, всё остальное — drop. Прямой коннект к порту
25454с любого другого адреса не должен проходить. - Секрет-заголовок
X-Cdn-Auth. CDN добавляет к проксируемым запросам секретный заголовок, а нода отвергает запросы без него. Это отсекает того, кто узнал IP ноды, но не знает секрета.
Вместе firewall и X-Cdn-Auth дают нужный результат: ноду видит только ваш CDN, а для всех остальных её как будто нет.
Экономика: сколько реально стоит трафик через CDN
CDN-трафик тарифицируется не только за гигабайты, но и за запросы — и для XHTTP это принципиально. Прайс за гигабайт — только половина счёта. Вторая половина у части провайдеров это запросы, а XHTTP в режиме packet-up дробит аплинк на множество мелких обращений.
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.
| Составляющая | Порядок величины |
|---|---|
| Сырой CDN-трафик | зависит от провайдера |
| С учётом платы за запросы (на масштабе) | зависит от провайдера |
Учёт трафика в панели и чего CDN не решает
Панели (Remnawave, 3x-ui, Marzban, Hiddify) держат за CDN обычный XHTTP-инбаунд, поэтому учёт трафика остаётся штатным. В Remnawave полезны два механизма:
- множитель потребления ноды: множитель
0означает, что трафик через эту ноду не засчитывается против лимита пользователя — нода при этом работает; - per-user лимиты: как обычно, ограничивают потребление на аккаунт.
И важное разграничение, чтобы не обещать клиентам лишнего. Whitelist-CDN решает ровно одну задачу — пробить троттлинг/белый список оператора, чтобы туннель вообще поднялся. Он не разблокирует российский стриминг: сервисы вроде Kinopoisk банят датацентровые IP по репутации, и для их контента нужен резидентный IP. Это отдельная задача, которую whitelist-CDN не закрывает. «Пробить троттлинг» и «разблокировать стриминг» — разные вещи, и путать их не стоит.