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