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