Зачем CDN-фронтинг: работать под белыми списками

Когда узел банят по IP, а не по протоколу, помогает CDN: клиент идёт на адрес CDN, а тот тянет трафик с твоей ноды. Разбираю, зачем это нужно, что за CDN прячется, а что нет, и почему такой фронт выживает даже при белых списках. Теория без команд.

Проблема: банят по IP

Есть разные способы прижать VPN-узел. Один из грубых, но действенных — забанить его по IP: адрес твоей ноды просто перестаёт быть доступным. Не важно, какой у тебя протокол и как хорошо он маскируется — если до IP не достучаться, всё остальное неважно.

Тут и выходит на сцену CDN-фронтинг. Идея простая: клиент подключается не к твоей ноде напрямую, а к адресу CDN. CDN — это сеть серверов-посредников, которые тянут трафик с твоего сервера-источника («origin»). Снаружи виден только IP CDN. Забанить твою ноду по IP больше нельзя, пока живёт CDN — а банить сам CDN операторы не станут, за ним стоят тысячи легальных сайтов.

Что можно спрятать за CDN, а что нет

Важное ограничение, на котором спотыкаются. За CDN проходят не любые транспорты, а только те, что работают поверх обычного HTTP.

• Проходит: XHTTP (создан прямо под CDN), в некоторых случаях WebSocket. Это транспорты, которые выглядят как обычные HTTP-запросы, — CDN их пропускает без вопросов.
• Не проходит: Reality поверх сырого TCP (flow: xtls-rprx-vision). Он не HTTP по своей природе, и через CDN его прогнать нельзя.

Поэтому CDN-фронтинг — это про XHTTP. Если ты сидишь только на Reality-Vision, за CDN он не спрячется — это надо понимать до того, как строить схему.

Как это устроено в РФ-реалиях

Тут есть тонкость, специфичная для российского контекста. РФ-шные CDN (Yandex, Timeweb, Selectel, Beget) фронтят российский источник — значит, CDN ставится на РФ-ноду (вход), а не на заграничную. Но выходить-то трафик должен из-за рубежа, иначе клиент получит российский IP со всеми геоблоками.

Решение — каскад: РФ-нода за CDN делает мост на заграничный выход. Итоговая цепочка:

клиент → CDN (российский IP эджа) → РФ-нода (origin) → мост → заграничный выход → интернет

Что это даёт: снаружи виден только IP CDN; вход российский (а свои подсети РФ-CDN не банят); а реальный выход в интернет — заграничный. Вешать CDN на заграничную ноду смысла нет — РФ-CDN её не зафронтят, а западные в РФ ненадёжны.

Два режима: «через GET» и «через POST»

Тут без глубокой техники, но понимать полезно. XHTTP разделяет канал на две HTTP-транзакции: скачивание вниз идёт как длинный GET, отправка вверх — как POST.

• «Через POST» (режим packet-up) — максимально совместимый с CDN: короткие POST вверх + длинный GET вниз. Работает почти везде.
• «Через GET» — упор на длинные потоки, меньше запросов, ниже задержка, но CDN должен уметь долгоживущие соединения.

Зачем это знать: некоторые CDN режут метод POST. Тогда приходится переводить транспорт в GET-only — данные отправки уходят в HTTP-заголовках. Это не блажь, а обход конкретного ограничения конкретного CDN.

Что нужно от любого CDN

Чтобы XHTTP через CDN не рвался, от провайдера нужны четыре вещи. Без них поток разваливается:

1. Разрешены методы GET и POST (POST часто выключен по умолчанию).
2. Кеш отключён на пути прокси — иначе CDN закеширует поток, и всё ломается.
3. Проброс заголовков к origin без переписывания.
4. Большие таймауты, без буферизации — длинный GET не должен обрываться.

Если провайдер хоть одно из этого не даёт — он не подходит под фронт, как бы красиво ни выглядела панель.

Честно про РФ-CDN

Не буду продавать иллюзию: проверенных «из коробки» РФ-CDN под эту задачу мало. Часть провайдеров документированно рвёт потоковые сессии, часть не подтверждает потоковое проксирование без кеша, часть даёт методы, но не даёт явного отключения кеша по пути.

Самый предсказуемый из российских — Yandex Cloud CDN (в режиме GET-only), из зарубежных — Cloudflare. Остальные РФ-CDN стоит рассматривать как резервный канал и обязательно тестировать перед боем.

Связь с белыми списками

Отдельная ценность CDN-фронта вылезает при веерных отключениях, когда мобильный интернет в РФ оставляют работать только по «белому списку» ресурсов. Обычный VPS-IP в это время недоступен в принципе — это не блок, а allow-list.

А вот сеть крупного CDN (тот же Yandex) часто попадает в разряд «своих» для фильтрации — трафик к ней не режут. Поэтому CDN-фронт может оставаться живым даже там, где прямая нода мертва. Это делает его не просто «обходом бана по IP», а инструментом выживания под белыми списками.

Итог: как встраивать

CDN-фронтинг — это резерв, а не основной канал. Основным держи прямой Reality (он быстрее, без лишнего звена). А XHTTP за CDN добавляй вторым хостом в подписку: прямой канал лёг по IP-блокировке или под белыми списками — работает CDN. Всегда давай клиенту подписку с несколькими хостами, чтобы один лёг — работал другой.

Помни про границы: CDN-фронт добавляет задержку и хорош для мессенджеров и браузинга, но тяжёл для больших загрузок и скорости. Это узел выживания, не скоростной.

Дальше — в практике: там я показываю пошагово, как поставить Yandex CDN перед нодой, включая обход блокировки POST через GET-only. Как работают сами белые списки — в отдельной теории раздела.