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