Colitu Adaptive Connect 2.0 и резервный канал: технический отчёт

#Аннотация

Некоторые сети блокируют VPN-протоколы; другие ведут себя хитрее: позволяют соединению установиться, а через несколько десятков секунд тихо останавливают трафик. В такой сети «отвечает на пинг» и «передаёт трафик» — не одно и то же. В отчёте описан набор механизмов, которыми приложения Colitu решают эту проблему, — Colitu Adaptive Connect 2.0: ранжирование серверов с учётом близости и приватности, память по сетям, которая хранится только на устройстве, подсказки сети на основе анонимных счётчиков, проверка при подключении по реальному трафику, переход на другой сервер, резервный канал, который держится наготове внутри работающего соединения, и наблюдение во время сессии для каждого транспорта. Оценка проводилась на одном телефоне Android в одной домашней сети Wi-Fi в стране с активной глубокой инспекцией пакетов (DPI); сбои вносились на сервере только для этого клиента. В лучшей конфигурации, когда основной путь был отрезан на 120 секунд, VPN оставался включённым, переподключения не было, а перерыв длился примерно 5–10 секунд. В 60-минутном тесте на выносливость с 11 сбоями на 8 серверах успешными были 98,8 % проверок через туннель; когда используемый сервер был полностью отрезан на 101 секунду, пользователь увидел лишь паузу примерно 5 секунд, и VPN оставался включённым. Ограничения и ещё не измеренные случаи перечислены отдельно.

#1. Введение

1. 1
   Первая задача VPN-приложения — подключиться к правильному серверу в правильном режиме. Серверы Colitu предлагают пять режимов подключения из четырёх семейств протоколов: Hysteria2 (UDP/QUIC), VLESS Reality, VLESS XHTTP, Trojan и Shadowsocks 2022 (см. Технические подробности).
2. 2
   Классический подход ранжирует серверы по пингу и выбирает самый быстрый. Но пинг — лишь подсказка: в некоторых сетях сервер отвечает на пинг и при этом вообще не передаёт трафик.
3. 3
   Бывает и сложнее: соединение устанавливается, приложение пишет «Подключено», но через некоторое время трафик останавливается, а TCP-соединение по-прежнему выглядит открытым. Для пользователя это значит: VPN включён, а интернета нет.
4. 4
   Adaptive Connect 1.x решал часть этих проблем, но наши измерения показали два важных пробела: список серверов приходил в порядке идентификаторов в базе данных, а наблюдение во время сессии охватывало только Hysteria2 (см. раздел 4).
5. 5
   Цель Adaptive Connect 2.0: при подключении найти путь, который действительно работает; во время подключения заметить сломавшийся путь и перевести пользователя на другой, по возможности не выключая VPN; и делать всё это, не собирая сведений о пользователе.

#2. Модель угроз и сбоев

Устройство рассчитано на перечисленные ниже типы сбоев. Они основаны на поведении, которое встречается в некоторых сетях и у некоторых мобильных операторов, а не в какой-то конкретной стране.

Допущения:

1. 1
   Одна сеть может блокировать режим, а другая — нет, поэтому «работает» — это свойство сети.
2. 2
   Сеть может замораживать все TCP-режимы одного сервера сразу; тогда другой TCP-режим на том же сервере бесполезен как резерв.
3. 3
   Интернет может пропасть у самого устройства; в этом случае ни один режим не должен считаться виноватым.

#3. Устройство

Описанные ниже механизмы разработаны для приложений Windows, Linux, Android (включая TV) и iOS. Все механизмы одинаковы во всех приложениях. Измерения из раздела 4 проводились на одном телефоне Android.

3.1 Ранжирование серверов

1. 1
   Выбранное пользователем местоположение используется как есть. Colitu никогда сам не меняет ручной выбор.
2. 2
   В автоматическом режиме («Самый быстрый сервер») порядок такой:

1. 1
   «Рекомендуемый» в списке серверов всегда показывает сервер, к которому подключится автоматический режим.
2. 2
   Приватность: чтобы упорядочить список, панель определяет вашу страну и сеть вашего интернет-провайдера только по IP-адресу этого запроса. Ничего не сохраняется. Если запрос идёт через VPN, панель их не знает, и приложение использует последние известные значения.

3.2 Память по сетям

1. 1
   «Сеть» — это тип подключения (Wi-Fi, мобильные данные, Ethernet) вместе с сетью вашего интернет-провайдера. Домашний Wi-Fi и мобильные данные запоминаются отдельно.
2. 2
   Память хранится только на устройстве:

1. 1
   Старые записи удаляются; хранится не более 200 записей.
2. 2
   В результате режим, заблокированный в мобильной сети, дома по Wi-Fi всё равно пробуется первым.

3.3 Подсказки сети

Память одного устройства знает только опыт этого устройства. Подсказки сети передают опыт других устройств в той же сети, никого не идентифицируя.

1. 1
   Подписанный токен сети. Панель выдаёт приложению токен со страной и номером сети (ASN), подписанный HMAC и действительный 48 часов.
2. 2
   Отправка наблюдений. Приложение отправляет результаты по каждому протоколу вместе с этим токеном. IP-адрес запроса никогда не используется для наблюдений: во время подключения это всё равно адрес VPN-сервера.
3. 3
   Анонимные почасовые счётчики. Панель хранит только почасовые счётчики по (стране, ASN, протоколу): успехи, отказы и число разных устройств. Разные устройства считаются через почасовые псевдонимы с ключом, которые удаляются по окончании часа. Счётчики хранятся 7 дней.
4. 4
   Пороги. Протокол считается «заблокированным в этой сети», если за последние 24 часа его пробовали не менее 5 устройств и доля успехов ниже 20 %. Если данных по сети мало, используется уровень страны: не менее 20 устройств и меньше 10 % успехов.
5. 5
   Никогда не все. Все предлагаемые протоколы никогда не отмечаются как заблокированные.
6. 6
   Использование. Ответ со списком серверов сообщает заблокированные протоколы. Приложение пробует их последними, если только протокол не работал на этом устройстве в этой сети за последние 24 часа.

3.4 Проверка при подключении и проверочный путь

1. 1
   Режим считается рабочим только тогда, когда идёт реальный трафик. Проверка обращается через туннель к распространённым адресам проверки связи (Cloudflare, Google, Microsoft), а не к серверам Colitu. На режим уходит примерно 4–6 секунд.
2. 2
   Прежде чем отметить режим как нерабочий, приложение проверяет, есть ли у устройства интернет вообще, чтобы пропавший Wi-Fi не списывался на режим.
3. 3
   Бюджет времени: примерно 8 секунд на режим (запуск и проверка трафика), примерно 20 секунд на сервер, не более примерно 45 секунд на всё подключение. Обычно хватает нескольких секунд.
4. 4
   Android показывает «Подключено» только после успешной проверки, до этого — «Проверка…».
5. 5
   Проверочный путь. При каждом запуске ядра добавляется закрытый проверочный вход, доступный только с самого устройства (со случайным портом и случайными учётными данными). Первое правило маршрутизации направляет его прямо в основной путь. Поэтому проверка при подключении измеряет только основной путь: сломанный основной путь не может спрятаться за резервным, и при следующем подключении его избегают.

3.5 Переход на другой сервер

1. 1
   В автоматическом режиме, если ни один режим сервера не прошёл проверку, приложение переходит к следующему серверу в списке, не более 3 серверов за одно подключение. В это время показывается «Пробуем другой сервер…».
2. 2
   Отказавший сервер остаётся в конце списка в этой сети на 30 минут.
3. 3
   В Windows и Linux при включённом kill switch автоматическая повторная попытка идёт вниз по списку, а не повторяет тот же сервер.
4. 4
   Если на вручную выбранном сервере отказали все режимы, в сообщении об ошибке предлагается «Попробовать самый быстрый сервер» одним нажатием.

3.6 Резервный канал

Топология. Во время подключения приложение держит наготове второй путь внутри работающего соединения. Трафик идёт через балансировщик: пока основной путь исправен, всё идёт по нему; если он перестал работать, новый трафик сам переходит на резервный. VPN остаётся включённым, экран «переподключение» не появляется. Поскольку переключение происходит в самом соединении, а не в интерфейсе приложения, оно работает и в фоне. Резервный канал подключается только тогда, когда он используется.

Выбор резервного канала.

Режимы и серверы, которые отказали в этой сети, никогда не становятся резервными.

Ловушка префикса. В Xray селекторы балансировщика и обсерватории сопоставляют теги по префиксу. Если бы тег резервного канала начинался с того же префикса, что и тег основного пути, обсерватория считала бы основным путём и резервный. Поэтому тег резервного канала выбран так, чтобы не иметь общего префикса с основным.

DNS. Для запросов DNS-модуля Xray есть явное правило, направляющее их в балансировщик.

TCP user timeout. При подключённом резервном канале TCP-пути используют тайм-аут пользователя TCP в 10 секунд (понятие из RFC 5482), чтобы мёртвые соединения закрывались, а не зависали.

Время обнаружения и затраты.

Kill switch в Windows разрешает и резервный сервер; Linux добавляет его в список разрешённых. Конфигурация резервного канала загружается параллельно с подключением, никогда его не задерживает и кешируется. Резервный канал включён по умолчанию; его можно выключить в Расширенном режиме, в Простом режиме он всегда включён.

3.7 Наблюдение во время сессии и правило с учётом резервного канала

1. 1
   В Adaptive Connect 1.x наблюдение во время сессии охватывало только Hysteria2. В 2.0 наблюдается каждый транспорт.
2. 2
   Частота: каждые 5 секунд первые 90 секунд, затем каждые 30 секунд. Три неудачи подряд, пока устройство в сети, означают, что основной путь считается мёртвым.
3. 3
   Правило с учётом резервного канала. При подключённом резервном канале наблюдатель отдельно проверяет две вещи: только основной путь и обычный путь (тот, которым пользуется балансировщик).

1. 1
   Это правило исправляет ошибку, замеченную в эксперименте 1 в разделе 4: старый наблюдатель перезапускал соединение, пока резервный канал передавал трафик, и ломал его.
2. 2
   Android и iOS сами переподключаются после неожиданного обрыва (примерно через 2, 5 и 15 секунд, затем показывается ошибка) и снова — когда сеть возвращается. Этого не происходит после нажатия «Отключить», выхода из аккаунта или когда тариф или устройство приостановлены.

3.8 Отметки зависания, которые не могут заблокировать сеть

Ошибочные отметки зависания могли бы оставить сеть без режимов для попытки. Это предотвращают два правила:

1. 1
   Если отметки оставили бы не больше одного из предлагаемых транспортов, в этом раунде они игнорируются.
2. 2
   Отметки, полученные в раунде, где всё отказало, действуют 10 минут. Срок 6 часов применяется только тогда, когда после этого другой транспорт передал трафик в той же сети, то есть когда проблема действительно касалась именно этого режима.

3.9 Отчёты серверов о подключённых и нагрузка

При каждом heartbeat серверы сообщают число разных подключённых пользователей (статистика онлайн-пользователей Xray и онлайн-интерфейс Hysteria2). Панель использует только полные отчёты; если статистику какого-то ядра получить не удалось, сохраняется предыдущее значение. В результате заполненные серверы больше не предлагаются, а распределение по нагрузке опирается на реальные числа. Эти отчёты работают на всех серверах.

3.10 Проверка резервного канала и параллельное подключение

Следующие два механизма есть во всех приложениях; оба были включены в тесте на выносливость из 4.3:

1. 1
   Проверка резервного канала. Резервный путь тоже проверяется примерно раз в минуту через собственный проверочный вход. Мёртвый резервный канал заменяется только тогда, когда туннель простаивает, и никогда во время звонка.
2. 2
   Параллельное подключение («happy eyeballs»). Два лучших кандидата проверяются одновременно, и побеждает тот, кто первым передаст трафик. Идея следует подходу Happy Eyeballs из RFC 8305.

#4. Оценка

4.1 Методика

Для этого написан внутренний инструмент («лаборатория сбоев»): он отрезает один протокол (на всех перечисленных серверах) или весь сервер для одного клиента помеченными правилами межсетевого экрана, снимает их самоудаляющимися таймерами, в течение часа каждые 5 секунд проверяет клиента и сообщает длительность перерыва для каждого сбоя. В экспериментах с резервным каналом из 4.2 сбои вносились по одному; в тесте на выносливость из 4.3 инструмент 60 минут вносил сбои в случайном порядке.

4.2 Результаты

Ранжирование. Сервер в стране пользователя показал наименьший пинг (13–15 мс), но был правильно поставлен после ближнего зарубежного сервера (16–17 мс). В Adaptive Connect 1.x список приходил в порядке идентификаторов в базе данных, и «Рекомендуемым» показывался сервер на другом континенте с пингом около 222 мс.

Наблюдение заморозки. В этой сети все TCP-транспорты к одному ближнему серверу (VLESS Reality, VLESS XHTTP, Trojan) замерзали примерно через 30–50 секунд после подключения: трафик останавливался, а TCP оставался открытым. Hysteria2 продолжал работать. Старый наблюдатель, охватывавший только Hysteria2, в этом случае показывал «Подключено» без трафика. Новый наблюдатель для всех транспортов обнаружил заморозку и сменил транспорт примерно за 1,3 секунды.

Базовая линия. Выпущенная версия 2.7.0 в той же сети проработала на Hysteria2 100 секунд без перерыва.

Эксперименты с резервным каналом (пакеты основного пути отбрасывались на сервере только для этого клиента):

4.3 Тест на выносливость

10 октября 2026 года на том же телефоне и в той же сети Wi-Fi был проведён 60-минутный тест на выносливость со сборкой Android, содержащей все механизмы 2.0 (включая проверку резервного канала и параллельное подключение), в автоматическом режиме.

1. 1
   Методика. Лаборатория сбоев внесла 11 сбоев на 8 серверах в случайном порядке; между сбоями было 2–5 минут, каждый длился 60–120 секунд. Использовались два типа сбоев: один протокол отрезан на всех серверах для этого клиента и один сервер полностью отрезан для этого клиента.
2. 2
   Проверка. HTTP-запрос через туннель каждые 5 секунд.
3. 3
   Результат. Успешными были 741 из 750 проверок (98,8 %).

Интерпретация.

1. 1
   Сбой 3 — ключевой случай: используемый сервер пропал на 101 секунду; пользователь увидел паузу примерно 5 секунд, VPN оставался включённым.
2. 2
   Сбой 11: в этой сети все TCP-протоколы замораживаются DPI. Когда Hysteria2 был отрезан везде, рабочего протокола не осталось; трафик вернулся через 2 секунды после окончания сбоя.
3. 3
   Сбои на неиспользуемых протоколах и серверах показывают 0 секунд, как и ожидалось: сбои в другом месте не нарушают сессию.

Ограничения. Одно устройство, одна сеть, один час; сбои вносились на стороне сервера, а не реальной системой цензуры.

Проверенные механизмы одинаковы во всех приложениях (Android, включая TV, iOS, Windows и Linux); измерение проводилось на одном телефоне Android.

4.4 Обсуждение

1. 1
   Эксперимент 1: одного резервного канала недостаточно; наблюдатель должен знать о нём. Этот эксперимент привёл к правилу с учётом резервного канала из 3.7.
2. 2
   Эксперимент 2: резервный канал на том же сервере бесполезен, если сеть замораживает все TCP-режимы этого сервера (допущение 2). Рабочего пути здесь не было вовсе; измеренное время — это сама блокировка, а не задержка механизма.
3. 3
   Эксперимент 3: правило «другого семейства» верно не для каждой сети. В этой сети семейство TCP замерзало целиком; выбрать другое семейство значило выбрать замёрзшее. Этот эксперимент привёл к правилу «доказанного транспорта» из 3.6: транспорт, работа которого в этой сети доказана, становится резервным на следующем сервере.
4. 4
   Эксперимент 4: при сочетании доказанного транспорта и другого сервера отрезанный основной путь отразился на пользователе лишь короткой паузой.
5. 5
   Тест на выносливость: полное отключение используемого сервера на 101 секунду свелось к паузе примерно 5 секунд; единственный долгий перерыв — сбой 11, когда не осталось ни одного рабочего протокола.
6. 6
   Наблюдение заморозки: разрыв между «Подключено» и «трафик идёт» — реальный тип сбоя, и наблюдать только за одним транспортом недостаточно.

4.5 Что ещё не измерено

Переход между Wi-Fi и мобильными данными и измерения iOS, Windows и Linux на реальных устройствах пока не проводились.

#5. Ограничения

1. 1
   Ротация выходного IP. Эта функция принудительно использует VLESS на одном сервере и отключает резервный канал. В измеренной сети это означало повторяющиеся заморозки. Это задокументированное ограничение.
2. 2
   Открытые TCP-потоки. При переключении на резервный канал звонки продолжаются после короткого сбоя, страницы и сообщения переподключаются сами; но большая загрузка, идущая в этот момент, может начаться заново. По-настоящему бесшовное продолжение загрузок — задача на будущее.
3. 3
   Одно устройство, одна сеть, один час. Оценка проведена на одном телефоне Android в одной сети, самый длинный тест длился один час; сбои вносились на стороне сервера, а не реальной системой цензуры. Результаты нельзя переносить на другие сети.
4. 4
   Устаревший ключ сети. Пока VPN включён, панель не видит, из какой сети пришёл запрос; приложение использует последнюю известную сеть, пока список не будет снова загружен с выключенным VPN.
5. 5
   Онлайн-счётчики. Пользователи, подключённые через sing-box, не входят в отчёты о подключённых; пользователь, подключённый к двум серверам, в общей сумме считается дважды.
6. 6
   Без резервного канала. С маршрутами multihop и на серверах с одним режимом резервного канала нет. sing-box не умеет работать с XHTTP.

#6. Дальнейшая работа: сессионный уровень CSL

Colitu Session Layer (CSL) — сессионный уровень, который планируется добавить поверх резервного канала. План находится в стадии черновика, и никаких сроков или результатов не обещается.

1. 1
   Что он добавляет. Сегодня резервный канал переводит на резерв новые соединения, но открытые загрузки и звонки через TCP могут оборваться. С CSL приложение открывает одну сессию, которая продолжается, даже когда меняется туннель под ней (носитель). В лабораторном прототипе самая длинная пауза составила 0,08–1,75 секунды, а загрузки без обрывов были проверены.
2. 2
   Его граница. Сессия CSL привязана к одному серверу; в первой версии перенести сессию на другой сервер нельзя. CSL решает проблемы в пределах одного сервера (переход между Wi-Fi и мобильными данными, блокировка протокола, мгновенный обрыв). Если отказывает сам сервер, включается резервный канал. Они не заменяют друг друга, а работают вместе.
3. 3
   Этапы. Сначала испытания с реальными туннелями (Reality, Trojan, Hysteria2) на временных тестовых серверах: обрыв, блокировка, смена сети и нагрузка; затем серверная служба, флаг включения для каждого сервера в панели и аварийный выключатель всего CSL; затем сначала Windows, потом Linux, Android и последним iOS. Среди целей — пауза не более 2 секунд при смене носителя, когда резерв готов, и скорость не ниже 90 % от прямого соединения.
4. 4
   UDP и звонки. Первая версия защищает только TCP; UDP (звонки WhatsApp и Meet, QUIC/HTTP3) остаётся под защитой резервного канала, как сейчас. Следующий шаг — передавать UDP внутри сессии CSL как датаграммы; при смене носителя ожидается пропуск короче 2 секунд. Также рассматривается необязательная настройка «принудительно TCP вместо QUIC» в Расширенном режиме.
5. 5
   Без CSL. Если на сервере флаг выключен, CSL не отвечает или сообщает «занят» либо «отказано», клиент за несколько секунд возвращается на сегодняшний путь. Сессия, оставшаяся без носителя дольше 90 секунд, теряется. Зависший клиент CSL завершает сторожевой процесс.
6. 6
   Как это получат пользователи. Как «Бесшовная сессия (бета)» в Расширенном режиме; по умолчанию выключено и показывается только на серверах с включённым флагом.

#7. Заключение

Главный вывод Adaptive Connect 2.0: работает ли путь, решает реальный трафик, а не пинг, и это решение зависит от сети. Ранжирование с учётом близости и приватности, память по сетям на устройстве, анонимные подсказки сети и проверка, измеряющая только основной путь, позволяют найти правильный путь. Во время подключения резервный канал вместе с наблюдателем, который охватывает каждый транспорт и учитывает резерв, превращает отрезанный основной путь в паузу примерно 5–10 секунд. В 60-минутном тесте на выносливость успешными были 98,8 % проверок, а полное отключение используемого сервера отразилось на пользователе паузой примерно 5 секунд. Оценка узкая; смена сети и измерения на других платформах — следующие шаги.

#Источники

1. 1
   RFC 8305, Happy Eyeballs Version 2: Better Connectivity Using Concurrency.
2. 2
   RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport.
3. 3
   RFC 5482, TCP User Timeout Option.
4. 4
   Документация проекта Hysteria2.
5. 5
   Документация проекта Xray-core.