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