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-трафик к «белому» домену.
Ошибка 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 нельзя переносить в клиентскую ссылку.
Если туннель встаёт и почти сразу рвётся — в 9 из 10 случаев дело именно в том, что uplink уехал в заголовок вместо тела.
Настройка ноды на Aeza за whitelist-CDN
Схема одинаково ложится на Remnawave, 3x-ui, Marzban и Hiddify. Принцип:
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Безопасность origin обязательна, иначе ноду найдут прямым сканом мимо CDN:
- файрвол на входе разрешает только IP gateway/edge, всё остальное — drop;
- секрет-заголовок
X-Cdn-Authна origin отсекает обращения, пришедшие не через CDN.
Так ваш IP на Aeza остаётся скрытым за whitelisted-входом, а прямой стук по адресу ноды ничего не даёт.
Экономика трафика и учёт в панели
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.
Учёт на стороне ноды — механизмы панели. В 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-слой на входе.