Почему единая точка входа — это риск
Классическая схема «клиент → нода» имеет одну точку отказа на каждом слое: один CDN-поддомен, одна edge-подсеть, одна нода. Достаточно, чтобы любой из них деградировал — и вход у части абонентов пропадает.
Под ограничениями это перестаёт быть теорией. Российские мобильные операторы при шатдаунах и блокировках переводят мобильный интернет в режим «белого списка»: доступны только whitelisted-ресурсы — часть CDN, госсайты. VPN, который ходит напрямую к своей ноде, в этот момент просто отваливается. Спрятать вход за whitelisted CDN-edge (например, Yandex CDN) — рабочий приём: оператор видит обращение к «белому» CDN, а CDN проксирует трафик на ноду.
Но и это не финальная защита. Whitelist привязан к подсетям /24 и меняется во времени; edge может деградировать; нода — упасть. Отсюда задача: не одна точка входа, а несколько независимых, с автоматическим переключением. Это и есть мульти-CDN и фейловер для VPN.
Три уровня фейловера
Устойчивость входа собирается из нескольких независимых слоёв. Каждый закрывает свой класс отказов — по отдельности ни один не даёт полной картины.
| Уровень | Что переключает | На какой отказ отвечает |
|---|---|---|
| Клиент | Между entry в подписке | Недоступен конкретный CDN-поддомен/edge |
| DNS | Между A-записями | Выпала edge-подсеть, смена IP |
| CDN edge (мульти-CDN) | Между CDN-провайдерами | Edge деградировал или выпал из whitelist |
| Origin group | Между нодами внутри CDN | Упала основная нода |
DNS-фейловер сам по себе медленный (TTL, кэш резолверов), поэтому опираться только на него нельзя. Практичная связка — origin group для отказа нод плюс мульти-CDN и клиентские entry для отказа edge. Слои складываются: клиентский переключается быстрее всего, origin group работает прозрачно для конфига, а мульти-CDN закрывает самый неприятный сценарий — падение самой точки входа.
Origin group: автопереключение нод внутри CDN
Origin group — это механизм самого CDN: группа origin-серверов (ваших нод) с приоритетами и проверкой доступности. Основную ноду вы помечаете как primary, вторую — как backup; CDN периодически проверяет health основной и при недоступности автоматически уводит трафик на резервную. Для оператора это прозрачно — клиентский конфиг не меняется, переключение происходит на стороне edge.
Каждая нода в группе держит одинаковый XHTTP-инбаунд: тот же порт (например, 25454), тот же path, host и extra. Если параметры на резервной ноде отличаются хоть на символ — после переключения туннель не поднимется, хотя health-check может считать origin «живым».
Важное ограничение: origin group cdn спасает от падения ноды, но не от того, что сам CDN-edge выпал из whitelist оператора. Health-check проверяет доступность origin со стороны CDN, а не то, доходит ли абонент до edge. Для этого класса отказов нужен следующий слой — мульти-CDN.
Мульти-CDN: диверсификация whitelist-риска
Мульти CDN — это несколько независимых CDN перед нодами. Смысл не только в запасе мощности, а в диверсификации whitelist-риска. Whitelist привязан к /24: edge-подсеть одного провайдера может быть в белом списке оператора, а соседняя — нет, и статус меняется. Если весь вход завязан на одну edge-подсеть, её выпадение обрушивает сервис целиком.
Ориентиры по хостерам (проверять актуально, без гарантий): подсети Selectel часто оказываются whitelisted; cloud.ru / SberCloud — часто нет. Это не константа — каждую /24 нужно проверять отдельно и повторно, желательно под реальным троттлингом, а не в обычном режиме сети.
Цена диверсификации — рост стоимости и сложности: дублирование конфигов, несколько origin group, отдельный учёт трафика. Считать по прайсу за гигабайт нельзя: CDN тарифицирует ещё и количество запросов, а XHTTP плодит много мелких обращений — итоговый счёт расходится с номиналом ₽/ГБ тем сильнее, чем интерактивнее трафик абонентов. Держать в горячем резерве второй CDN дороже, чем один, но это плата за то, что выпадение одной edge-подсети не выключает вход.
Клиентский фейловер и совпадение параметров
Самый быстрый слой переключения — на стороне клиента. В подписку отдаётся несколько entry, каждый указывает на свой CDN-поддомен (разные edge или провайдеры); клиент перебирает их, если текущий не отвечает. Это закрывает случай, когда конкретный edge недоступен именно у этого абонента и его оператора, хотя у других всё работает.
Условие работоспособности одно, но жёсткое: path, host и extra в каждом entry должны точь-в-точь совпадать с тем, что настроено на ноде за соответствующим CDN. Клиентские приложения (семейство xray/v2ray-совместимых) не поднимут туннель при малейшем расхождении — и внешне это выглядит как «CDN не работает», хотя проблема в рассинхроне параметров.
Практический вывод для фейловера vpn: держите конфиги нод и записи в панели подписки как единый источник правды. Любое ручное редактирование path или host на одной стороне должно немедленно отражаться на другой, иначе резервный entry окажется «мёртвым» ровно в момент, когда он нужен.
XHTTP через CDN: где рвётся туннель
Транспорт под троттлингом — отдельная тема. XHTTP в режиме packet-up через CDN — рабочий подход; Reality и Hysteria2 напрямую под ограничениями обычно не проходят, потому что edge их не пропускает. Но у XHTTP через CDN есть неочевидная деталь, на которой рвётся большинство первых запусков.
Uplink-данные должны идти в теле запроса — uplinkDataPlacement: "body", а не в кастомном заголовке (типа X-Payload). Причина инфраструктурная: CDN-edge не доносит произвольные кастомные заголовки до origin, и туннель рвётся с unexpected EOF. Session и seq надёжнее класть в cookie, padding — в query-параметры. Заодно это влияет на кост: крупные POST в теле уменьшают число мелких запросов, а значит — плату за запросы.
Отдельный практический вывод: тестируйте транспорт именно через реальный CDN-edge, а не напрямую по IP ноды. Прямое соединение может подниматься, а через edge — падать; отладка «мимо CDN» даёт ложную картину.
Эксплуатация: защита origin и учёт трафика
Когда вход стоит за CDN, ноду нельзя оставлять открытой. Origin закрывается файрволом на вход только с IP gateway/edge, а секретный заголовок X-Cdn-Auth отсекает прямые обращения мимо CDN — иначе origin находят сканерами и бьют напрямую, и весь смысл whitelisted-входа теряется.
Учёт трафика — механизм панели. В Remnawave есть множитель потребления ноды и per-user лимиты: множитель 0 на ноде означает, что трафик через неё не считается против лимита абонента, при этом нода работает. Это удобно для резервных нод и тестов, но требует осознанного учёта, иначе экономика мульти-CDN «поедет».
И то, чего мульти-CDN не решает: стриминг. Сервисы вроде Kinopoisk банят датацентр-IP по репутации — для российского контента нужен резидентный IP, а whitelist-CDN эту задачу не закрывает. Не путайте «пробить троттлинг» (задача входа) и «разблокировать стриминг» (задача выходного IP) — это разные слои и разные решения.
Собрать и обслуживать всё это можно самостоятельно на Remnawave, 3x-ui, Marzban или Hiddify. Если не хочется держать собственный парк whitelisted edge и следить за статусом каждой /24, whitelisted-вход берётся как сервис — по этой модели работает Clearway (clear-way.pro): оператор подключает свои ноды за готовый CDN-edge (*.whitechannel-x1-cdn.ru), не покупая серверы.