Когда 3x-ui нужен вход за CDN
Когда мобильный оператор в РФ вводит ограничения или частичный шатдаун, сеть нередко переводится в режим белого списка: у абонента открыты только whitelisted-ресурсы — часть CDN, госсервисы, платёжные шлюзы. VPN, который ходит напрямую к вашей ноде по её IP, в этом режиме просто отваливается — адрес ноды в белый список не входит.
Идея входа за CDN проста: спрятать вход VPN за whitelisted CDN-edge. Для оператора трафик выглядит как обращение к «белому» CDN, а edge проксирует его на вашу origin-ноду с 3x-ui. Отсюда и связка 3x-ui + CDN: панель держит транспорт, CDN даёт «белый» вход.
Два ограничения, которые нужно понимать заранее:
- Whitelist привязан к подсетям (/24), а не к хостеру целиком. У одних провайдеров подсети попадают в белые списки, у других — нет, и статус меняется. Selectel часто оказывается whitelisted, cloud.ru / SberCloud — часто нет. Проверяйте каждую /24 отдельно и перепроверяйте актуально; гарантий по хостеру «вообще» не бывает.
- Транспорт решает. Через CDN стабильно проходит XHTTP в режиме
packet-up. Reality и Hysteria2 напрямую под троттлингом обычно не проходят — CDN-edge их не пропускает.
| Транспорт | Через whitelisted CDN | Напрямую под троттлингом |
|---|---|---|
| XHTTP (packet-up) | проходит | зависит от /24 |
| Reality | edge не пропускает | часто режется |
| Hysteria2 (UDP) | edge не пропускает | часто режется |
Как устроен вход и особенность 3x-ui
Схема входа: клиент → CDN-edge (443/TLS) → origin-нода (3x-ui, XHTTP-инбаунд). TLS терминируется на edge; между edge и вашей нодой идёт уже расшифрованный XHTTP, поэтому на самом инбаунде TLS не нужен.
Здесь есть особенность 3x-ui, о которой стоит знать до настройки. В отличие от Remnawave, 3x-ui не разделяет «инбаунд на сервере» и «адрес, который получает клиент»: панель исходит из того, что клиент подключается туда же, где стоит сервер, — по его IP. Мы же подключаемся через CDN-домен, поэтому автогенерированная ссылка или QR из панели ведёт на IP ноды напрямую и для входа за CDN не годится. Клиентскую ссылку придётся собрать вручную — один раз на инбаунд, не на каждого клиента.
XHTTP-инбаунд на ноде
В 3x-ui: Inbounds → Add Inbound. Базовые поля — Protocol VLESS, Listening IP 0.0.0.0, Port (например 25454), Network xhttp, Security none.
У XHTTP-инбаунда за CDN есть нестандартные параметры (размещение uplink, ключи session/seq/padding), под которые в обычной форме панели полей нет. Не ищите их в GUI — переключите редактор инбаунда в режим JSON (иконка </>) и задайте streamSettings целиком. Опорные значения:
| Параметр | Значение | Зачем |
|---|---|---|
network | xhttp | транспорт XHTTP |
security | none | TLS терминирует CDN-edge, не нода |
mode | packet-up | рабочий режим через CDN |
path | ваш путь, напр. /api/v1/sync/ | должен совпасть с клиентом |
port | напр. 25454 | слушает origin, куда ходит edge |
security: none здесь корректно: снаружи клиент идёт по TLS до edge, а edge отдаёт трафик на ноду уже расшифрованным.
Критичный нюанс: uplink в теле запроса
Это самый неочевидный момент всей связки 3x-ui xhttp за CDN. XHTTP умеет класть uplink-данные либо в тело запроса, либо в кастомный HTTP-заголовок (например X-Payload). Напрямую работают оба варианта. Через CDN — нет.
CDN-edge не доносит произвольные кастомные заголовки до origin: он их режет или не форвардит. Если uplink уходит в заголовок, до вашей ноды он не доезжает, и туннель рвётся — характерный симптом unexpected EOF в логах.
Правило: uplink должен идти в теле запроса — uplinkDataPlacement: "body". Служебные session/seq лучше класть в cookie, padding — в query: cookie и query edge передаёт корректно, кастомные заголовки — нет. Эти параметры задаются в extra инбаунда и должны один в один совпадать с клиентским конфигом.
Клиентская ссылка и совпадение параметров
Клиентская ссылка указывает на CDN, а не на IP ноды. В качестве Address, SNI и Host ставится поддомен whitelisted edge (у Clearway это *.whitechannel-x1-cdn.ru), на клиенте security = tls, type = xhttp, mode = packet-up.
Ключевое условие: path и extra на ноде и в клиенте должны совпадать точь-в-точь. Расходится хоть один символ пути или размещение session/padding — edge доводит запрос до origin, но XHTTP-инбаунд его не узнаёт, и туннель не поднимается. Шаблон ссылки собирается один раз; для новых клиентов меняется только UUID, остальное одинаково.
Напомним: автоссылку из самой 3x-ui использовать нельзя — она ведёт на сервер напрямую, мимо CDN.
Защита origin, учёт трафика и границы решения
Защита origin. Уникальный путь спасает от DPI-фингерпринтинга, но не от прямого обращения к ноде по IP мимо CDN. Закройте порт файрволом на вход — принимать соединения только с IP вашего gateway (именно он ходит на ноду). Дополнительно origin можно защитить секрет-заголовком (X-Cdn-Auth): edge добавляет его к запросам, нода отклоняет всё без него.
Прайс за гигабайт — только половина счёта. Вторая половина у части провайдеров это запросы, а XHTTP в режиме packet-up дробит аплинк на множество мелких обращений. Крупные POST'ы в теле (тот самый body-uplink) снижают число запросов и заодно кост. Per-client лимиты трафика и срок действия — штатные механизмы 3x-ui; учёт на стороне входа считается отдельно.
Границы решения. Whitelist-CDN пробивает троттлинг оператора, но не разблокирует стриминг. Сервисы вроде Kinopoisk банят датацентр-IP по репутации — для российского контента нужен резидентный IP, и это отдельная задача, которую CDN-вход не закрывает. Не путайте «пройти в белый список оператора» и «получить чистый IP для стриминга».
Если не хотите поднимать и держать whitelisted edge сами, Clearway даёт такой «белый» вход как сервис: вы держите свою 3x-ui-ноду, а вход перед ней остаётся в белых списках операторов.