Почему единая точка входа — это риск
Классическая схема «клиент → нода» имеет одну точку отказа на каждом слое: один 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-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Важное ограничение: 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 недоступен именно у этого абонента и его оператора, хотя у других всё работает.
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Практический вывод для фейловера vpn: держите конфиги нод и записи в панели подписки как единый источник правды. Любое ручное редактирование path или host на одной стороне должно немедленно отражаться на другой, иначе резервный entry окажется «мёртвым» ровно в момент, когда он нужен.
XHTTP через CDN: где рвётся туннель
Транспорт под троттлингом — отдельная тема. XHTTP в режиме packet-up через CDN — рабочий подход; Reality и Hysteria2 напрямую под ограничениями обычно не проходят, потому что edge их не пропускает. Но у XHTTP через CDN есть неочевидная деталь, на которой рвётся большинство первых запусков.
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.
Отдельный практический вывод: тестируйте транспорт именно через реальный 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), не покупая серверы.