Блог Clearway

Happ и белые списки: настройка подключения, которое переживает отключения

Коротко

Чтобы Happ работал в режиме белых списков, обычного VLESS-ключа на дата-центровом IP недостаточно: при веерном отключении мобильного интернета оператор пропускает трафик только на whitelisted-адреса, а VPS в этот список не входит. Рабочая связка — подписка, в которой сервер спрятан за легальным whitelisted-CDN (например, CDN Яндекса), транспорт XHTTP или Reality с корректным SNI и отдача подписки без кэша. Сам Happ ничего не «обходит»: он лишь исполняет маршрут из ключа. Решает не приложение, а IP назначения, к которому вы подключаетесь.

Что такое белые списки и почему обычный Happ-ключ перестаёт работать

«Белый список» (whitelist) — режим, который оператор связи включает во время веерных отключений мобильного интернета: 2G/4G отдаёт данные, но маршрутизируется только ограниченный набор IP и доменов — госуслуги, банки, крупные маркетплейсы, платёжные системы, у части операторов CDN Яндекса и VK. Всё остальное, включая обычные VPN, не открывается, даже если сам VPN-сервер жив и отвечает на других сетях.

Happ — клиент для VLESS/Reality/XHTTP: он читает подписку и поднимает соединение по параметрам из ключа. Приложение не «пробивает» блокировку. Если в ключе прописан дата-центровый IP (Hetzner, DigitalOcean, любой VPS), в режиме белого списка оператор не пропускает пакеты до этого адреса — и Happ висит на «Connecting» или отдаёт таймаут.

Вывод, который стоит принять сразу: дело не в настройках интерфейса Happ, а в том, куда ведёт ключ. Фильтрация в этом режиме идёт по IP назначения, поэтому отключение переживает только трафик, чей первый хоп попадает на whitelisted-ресурс. Проверить принадлежность IP к работающей подсети до отключения нельзя со стороны клиента — это знает только конфигуратор сети оператора, поэтому набор whitelisted-подсетей всегда указывают как «у ряда операторов», а не как гарантию.

«Ключи» и «подписка» в Happ: в чём разница

В Happ конфигурация добавляется двумя способами:

  • Ключ — одна строка vless://... с сервером, портом, транспортом, SNI и путём. Это один фиксированный маршрут, который вы обновляете вручную.
  • Подписка — ссылка https://.../sub/..., по которой Happ скачивает список ключей и периодически его обновляет. Оператор сервиса меняет серверы на своей стороне — у вас конфиг подтягивается сам.

Для режима белых списков подписка практичнее ровно по одной причине: когда конкретный /24 CDN выпадает из белого списка оператора, провайдер сервиса меняет фронт-хост у себя, и вам не нужно переустанавливать ключ вручную в момент, когда интернет уже наполовину лежит.

Важный нюанс про запрос «ключи для happ белый список»: особого формата ключей под Happ не существует. На практике имеют в виду обычные VLESS-ключи, у которых сервер спрятан за whitelisted-CDN. Значение имеет не «магия ключа», а хост назначения и транспорт — всё остальное в строке vless:// роли для проходимости не играет.

Настройка Happ под белые списки: пошагово

Настройка happ белые списки сводится к добавлению правильной подписки и проверке, что транспорт совместим с CDN:

  1. Happ → «+» → Добавить подписку → вставьте ссылку от вашего сервиса.
  2. Дождитесь загрузки конфигов. В списке серверов ищите отмеченные как «CDN» / «whitelist» или с доменным SNI известного CDN — именно они переживают отключения. Дата-центровые ноды в этом режиме бесполезны.
  3. Включите автообновление подписки. На iOS Happ склонен держать старый конфиг — если новые серверы не появились, удалите подписку и добавьте заново (со стороны сервиса это лечится заголовками no-cache при отдаче подписки).
  4. Выберите whitelisted-сервер, подключитесь, проверьте выход по IP (любой сервис определения IP).
  5. Проверьте связку заранее, до реального отключения. В обычном режиме работает всё, и whitelisted-ключ визуально не отличить от обычного — единственный честный тест это реальное отключение, которого лучше дождаться подготовленным.

Если в одном приложении ключ работает, а в Happ нет (или наоборот) — частая причина в транспорте XHTTP: CDN без POST вынуждает клиента ходить через GET, и тогда в ключе обязателен явный режим packet-up. Это правится на стороне сервера, в интерфейсе Happ такой опции нет.

Почему whitelisted-CDN хост — ключевой элемент

Механика обхода белых списков для Happ держится на одном приёме: трафик должен физически идти на IP, который у оператора уже в белом списке. Практичнее всего это IP крупного CDN (например, CDN Яндекса) — от него зависят сервисы, которые оператор не станет ронять целиком.

Схема: Happ подключается к домену CDN (whitelisted-адрес) по 443, CDN проксирует запрос на ваш реальный VLESS-сервер. Для DPI оператора это обращение к «белому» CDN-домену по HTTPS — неотличимо от обычного веб-трафика.

На этом принципе построен подход whitelist-CDN как сервис для VPN-операторов: фронт через легальный CDN-домен, за которым спрятана VPN-нода. Оператору сервиса это даёт клиентам подключение, не отваливающееся при веерных отключениях; пользователю — подписку, чьи ключи «просто работают».

Тип хоста в ключеОбычный режимРежим белого списка
Дата-центровый IP (VPS)РаботаетНет: IP не в списке
Reality с чужим SNI, но DC-IPРаботаетНет: фильтр по IP, не по SNI
Whitelisted-CDN фронтРаботаетДа, пока подсеть CDN в списке

Ключевое: подмена SNI сама по себе не спасает. В режиме белого списка решение о пропуске принимается по IP назначения, а домен в SNI на это не влияет — красивый SNI на дата-центровом IP отключение не переживёт.

Честно про качество: скорость, задержка, цена

Whitelisted-CDN даёт проходимость, но не бесплатно по качеству. Оценки ниже — ориентировочные, конкретика зависит от вашего оператора, ноды и региона:

  • Задержка выше. Лишний узел (клиент → CDN → нода) обычно добавляет к пингу порядка 20–80 мс против прямого VLESS.
  • Полоса упирается в ноду и транспорт. XHTTP поверх CDN менее эффективен, чем Reality напрямую: часть пропускной способности съедает оверхед на запросах, реальная скорость чаще ниже прямого ключа.
  • CDN-статус не вечен. Сегодня подсеть CDN whitelisted, завтра конкретный /24 выпал — поэтому подписка с быстрой сменой фронта надёжнее статичного ключа.
  • Реальная удельная стоимость выводится только из собственного биллинга: она зависит от профиля трафика абонентов и от того, тарифицирует ли провайдер запросы.

Честный вывод: whitelisted-ключ — это не «быстрее», а «работает тогда, когда всё остальное лежит». Разумная схема — держать в Happ два ключа: быстрый прямой (Reality) на обычные дни и whitelisted-CDN как резерв на период отключений.

Частые проблемы и что проверить

  • Happ на iOS показывает старый конфиг / не обновляет подписку. Клиент кэширует. Удалите подписку и добавьте заново; со стороны сервиса помогает отдача подписки с заголовками no-cache.
  • Ключ подключается, но интернета нет. XHTTP через CDN в GET-режиме требует явного mode packet-up. Правится на сервере, не в Happ.
  • В одном клиенте работает, в Happ нет (или наоборот). Разное поведение с GET/POST на CDN. Проверьте, что в конфиге на сервере задан packet-up.
  • В обычные дни всё ок, при отключении — нет. Выбран ключ на дата-центровом IP. Переключитесь на CDN-сервер из подписки.
  • Периодически отваливается конкретный whitelisted-сервер. Его подсеть CDN временно выпала из белого списка оператора — дождитесь обновления подписки или смените сервер вручную.

Частые вопросы

Как настроить Happ, чтобы работал при отключении интернета по белым спискам?

Добавьте подписку, в которой есть сервер за whitelisted-CDN (фронт через легальный CDN-домен). Обычный VLESS-ключ на дата-центровом IP в этом режиме не работает — оператор не пропускает трафик до такого IP. Выберите CDN-сервер из подписки и проверьте связку заранее, до реального отключения.

Что такое «ключи для happ белый список» и чем они отличаются от обычных?

Формат тот же — обычный vless://. Отличие в том, что сервер спрятан за whitelisted-CDN хостом, а транспорт (чаще XHTTP) настроен под CDN. Особых «ключей Happ» не существует: значение имеют только IP назначения и настройки на стороне сервера.

Happ сам обходит белые списки?

Нет. Happ — клиент, он отправляет трафик по маршруту из ключа. Обход обеспечивает сервер: трафик должен физически идти на IP, который у оператора уже в белом списке (например, CDN Яндекса). Happ лишь исполняет этот маршрут.

Почему в одном приложении ключ работает, а в Happ — нет?

Частая причина — транспорт XHTTP через CDN. CDN без поддержки POST вынуждает использовать GET, и тогда в конфиге обязателен явный режим packet-up. Без него часть клиентов подключается, а часть нет. Правится на сервере, а не в интерфейсе Happ.

Почему Happ на iOS не обновляет подписку и показывает старые ключи?

Happ на iOS кэширует подписку. Помогает удалить её и добавить заново, либо чтобы сервис отдавал подписку с заголовками no-cache. После этого новые whitelisted-серверы подтянутся.

Whitelisted-CDN ключ будет быстрым?

Обычно медленнее прямого Reality: лишний узел добавляет к пингу примерно 20–80 мс, а полоса упирается в ноду и оверхед XHTTP. Такой ключ ценен не скоростью, а тем, что работает во время веерных отключений. Разумно держать два ключа: прямой на каждый день и whitelisted-CDN как резерв.

Может ли whitelisted-сервер перестать работать?

Да. Белый список у оператора меняется, конкретная подсеть CDN может выпасть. Поэтому подписка с быстрой сменой фронт-хоста надёжнее статичного ключа: провайдер меняет хост у себя, и конфиг обновляется автоматически.

Обязательно ли использовать именно CDN Яндекса?

Не обязательно Яндекс, но нужен CDN или ресурс, реально попадающий у операторов в белые списки, чтобы IP назначения был заранее разрешён. У ряда операторов в списках оказываются крупные российские CDN — их и используют как фронт, но конкретный набор подсетей нужно проверять, гарантий по всем операторам нет.

Whitelisted-вход для вашего VPN-сервиса

Clearway даёт «белый» CDN-вход перед вашей нодой — устойчивый к троттлингу операторов. Первые 10 ГБ бесплатно, без карты.

Попробовать →