Зачем 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 сам по себе | Рабочий вариант |
Актуальные настройки XHTTP через CDN
Ошибка unexpected EOF сама по себе не определяет причину. В текущем входе Clearway GET с телом отклоняется CDN с ошибкой 413. Проверьте серверный auto и лимит заголовков, затем клиентский header; для других ошибок сопоставьте время и журналы клиента, CDN, gateway и origin. Ответ HTTP 200 и успешный TLS ещё не подтверждают передачу HTTPS через туннель. Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Практические правила размещения полей XHTTP через CDN:
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.
Хостер и подсеть: 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 остаётся доступен напрямую и теряет смысл маскировки.
Экономика трафика и учёт в панели
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.
Учёт трафика — на стороне панели (Remnawave, 3x-ui, Marzban, Hiddify). Множитель потребления ноды и per-user лимиты — механизмы панели: множитель 0 на ноде означает, что трафик через неё не считается против лимита пользователя, при этом нода продолжает работать. Это удобно для fallback-ноды за CDN, которую не хочется тарифицировать наравне с основной.
Whitelisted-вход можно строить самому или брать как сервис. Clearway (clear-way.pro) даёт операторам готовый whitelisted CDN-edge (домены *.whitechannel-x1-cdn.ru) перед их нодами — без продажи серверов: ноды остаются у оператора, наружу торчит только «белый» поддомен.