0摘要
Adaptive Connect 2.0 让应用学会了发现连接期间出现故障的路径，并把流量转移到热备用。现场数据暴露出三个薄弱点：诊断一次中断需要几十秒；应用在不认识的网络上只能盲目尝试；同一套逻辑在四个平台上分别编写，决策逐渐出现分歧。Adaptive Connect 3.0 针对这三点：由匿名汇总数据得出的网络提示，让应用第一次尝试就以正确的连接模式开始；恢复集，即使 API 无法访问也能找到可用的服务器；约 11 秒内诊断出中断的监视器；以及四个应用都遵守的含 46 个向量的共用规则集。本报告介绍 3.0 的架构、分阶段推出和测量结果，并把仍处于 alpha 或仅在计划中的部分单独列出。
1为什么要有 3.0？
2.0 发布后的第一周，我们从两个来源收集了数据：注入故障的实验室运行，以及应用发送的匿名连接遥测（其结构见隐私部分）。在针对 29 台服务器的 2.0 实验室基线测量中，85.2 % 的探测成功；问题集中在特定的故障类型上（实验室报告）。
| 发现 | 来源 | 结果 |
|---|---|---|
| 中断诊断缓慢 | 现场遥测 | 从检测到恢复的平均时间：Android 54 秒，Windows 34 秒 |
| Windows 上的连接长尾 | 现场遥测 + 测试电脑 | 首次尝试即成功的连接平均耗时 14.9 秒；根本原因：断网保护 (kill switch) 保持期间，API 地址只存在于内存中 |
| 热备用有时始终没有接管 | 实验室 | 由于后台流量超过阈值，切换到热备用被无限期推迟 |
| 在新网络上盲目起步 | 现场遥测 | 在没有记忆的网络上，应用按固定顺序尝试各模式 |
| 各平台出现分歧 | 代码审查 | 同一条规则用四种语言分别编写；Windows 和 Linux 在排序和提示解析上存在差异 |
因此 3.0 的目标不是新的协议，而是决策质量：更少的尝试、更短的盲区时间、每个平台上相同的决策。不会向用户收集任何额外数据，手动选择的位置也绝不会被更改。
2架构：七个组件
3.0 从一开始就被设计为由七个组件构成的框架。它们的成熟度并不相同；下表如实列出每个组件目前的状态。
| 组件 | 作用 | 状态 |
|---|---|---|
| 集体网络提示 | 根据匿名汇总数据，推断某个网络上哪种连接模式可用 | 已上线 |
| 预测式启动 | 在不认识的网络上，应用以提示中的模式开始；依靠规则，不使用机器学习 | 已上线 |
| 自主恢复 | 即使 API 无法访问，也使用保存在设备上的恢复集和已保存的地址进行连接 | 已上线 |
| 快速中断检测 | 在连接期间约 11 秒内诊断出中断，并决定何时离开服务器 | 已上线 |
| 网络实验室 | 故障注入包以及跨平台共用的测试向量 | 已上线（内部工具） |
| 连续性引擎 (CSL) | 一个会话层，即使隧道变化也能保持会话不中断；多条承载通道 (lane) | Alpha（Windows，测试账户） |
| 自适应伪装 | 根据网络选择流量形态和传输设置 | 计划中 |
网络提示 v2
应用会匿名上报每次连接尝试的结果（模式、成功或失败、耗时）。面板把这些结果汇总为按网络划分的每日合计，即国家/地区 + 自治系统 (ASN) 级别。如果某个网络的数据足够，服务器列表会连同一个 `preferred` 顺序一起返回：该网络上最近 24 小时内可用的模式，成功率高的排在前面。网络变化时，应用会重新获取列表，并使用新网络的提示。
在 10 月 16 日的测量中，过去七天共出现 89 个不同的网络；其中 44 个有足够的数据可供决策，并为 40 个生成了偏好顺序。在某些网络上，基于 UDP 的 Hysteria2 成功率为 92 %，而 TCP 模式在 44–54 % 之间；固定顺序会让这些网络上的每次连接都浪费时间。
恢复集
在 2.0 中，如果无法从 API 获取服务器列表，应用就无处可连。在 3.0 中，应用在 API 正常响应时大约每天下载一次小型恢复集并保存在设备上：这是针对不同国家/地区的几台服务器的完整配置，有效期比普通配置长得多。首先选择该设备最近几天访问过的服务器，然后从每个国家/地区各选一台；这样即使某个国家/地区的服务器无法访问，其他的仍然可用。只有在所有 API 地址都没有响应、且常规缓存也无法连接时才会使用恢复集；连接建立后，应用会通过隧道内部访问 API 并刷新所有内容。
此外，Windows 和 Linux 应用现在把 API 地址保存在磁盘上，并并行刷新。当断网保护 (kill switch) 沿用上一次运行的状态时（崩溃或重启后自动连接），系统 DNS 处于关闭状态，因此 2.0 会依次尝试解析各个地址，从启动到连接需要 21–25 秒。
快速中断检测
监视器每秒探测一次主路径，超时为三秒。单次丢失还不是决定；当连续丢失得到确认后，会在约 11 秒内做出中断判定。判定之后怎么做，取决于中断的范围：
| 情况 | 决策 |
|---|---|
| 仅主路径中断，热备用正常 | 流量留在热备用上；先尝试同一服务器上的其他模式 |
| 主路径与热备用同时中断，设备在线 | 在自动模式下，该服务器针对这个网络被降级 30 分钟，并切换到下一台服务器 |
| 设备自身的互联网中断 | 不归咎于任何模式或服务器；网络恢复后重新连接 |
| 手动选择的位置 | 不更换服务器；只在同一位置的各模式之间切换 |
2.0 中的一个缺陷也已修复：当后台持续存在少量流量时，切换到热备用会以“忙碌”为由被无限期推迟。在 3.0 中，推迟最多限于两分钟或 32 KB。
即时设备身份
每台设备在每台服务器上都有自己专属的身份。在 2.0 中，新身份只能在每 15 秒一次的定期同步时才到达服务器，因此新用户的首次连接可能因此失败 15–30 秒。现在，身份变更会立即传给服务器；配置请求会稍作等待，如果身份仍未就绪，应用会知晓这一点，并每隔两秒重试。
3共用决策规则与 Go 引擎
Adaptive Connect 的规则存在于四个应用中，使用四种不同的语言：Kotlin (Android)、C# (Windows 和 Linux)、Dart 和 Swift (iOS)。3.0 把这些规则绑定到唯一的来源：共用测试向量。每个向量包含一份输入（服务器、测量值、记忆、提示）和预期的决策；四个应用的测试套件运行的是同样的文件。
| 向量文件 | 覆盖范围 |
|---|---|
| ranking | 自动模式下的服务器排序：最近可用、ping、惩罚、本国规则（19 个用例） |
| transport | 连接模式的基础顺序、带提示的启动、被忽略的标记 |
| hints | 提示响应的解析 |
| recovery | 恢复决策、刷新时间、恢复集的读取、下一台服务器 |
四个文件共有 46 个用例。如果某个应用中的规则发生变化，而其中某个向量给出了不同的结果，该应用的测试套件就会失败。
向量第一次运行时就发现了真实的差异：Windows 和 Linux 把推后本国服务器的规则应用到了所有国家/地区；在这两个应用中，一个不是数字的提示值可能破坏整个服务器列表的读取；Linux 只按延迟对 TCP 模式排序。所有这些都被合并为同一套规则。
同样的规则也在开源的 Go 软件包中实现，并通过同样的 46 个向量。该引擎以影子模式内置于 Android、Windows 和 Linux 应用中：连接时，应用自己的决策会与引擎的决策比较，出现差异则记录下来，但决策仍由应用做出。如果引擎报错，会被停用十分钟。当影子模式中的差异降为零时，决策将交给引擎；iOS 尚未内置该引擎。
4分阶段推出
3.0 的应用端以可远程决定是否启用的方式加入各版本：Android 2.9.2、Windows 2.9.7、Linux 1.5.3 和 iOS 5.9 系列。面板在服务器列表响应中返回 `features.adaptive_connect_3` 标志。哪台设备进入推出分组，由根据设备身份的 SHA-256 摘要得出的稳定分桶决定；只要百分比不变，同一台设备就留在同一分组。应用会保存最近一次的标志，并在无法访问 API 期间继续使用它。
| 日期 | 比例 | 平台 |
|---|---|---|
| 2026 年 10 月 16 日 | 10 % | Android、Windows、iOS |
| 2026 年 10 月 17 日 | 15 % | Android、Windows、iOS |
| 2026 年 10 月 20 日 | 100 % | Android、Windows、iOS |
远程启用的部分是带网络提示的启动和恢复集。快速中断检测、离开服务器的规则、已保存的 API 地址和共用规则随版本一同交付给了每位用户。Linux 被有意排除在远程推出之外：用户数量太少，无法进行比较，而且 1.5.3 版本出现了与 3.0 无关的连接错误增加。回退只需一个设置，无需更新应用。
5测量结果
| 测量项 | 2.0 | 3.0 | 测量方式 |
|---|---|---|---|
| 中断诊断 | 54 秒 (Android)、34 秒 (Windows)，现场平均值 | 约 11 秒 | 监视器节奏；单元测试和测试电脑 |
| 通往服务器的流量被切断 45 秒时的总中断时间 | 50 秒 | 22.4 秒 | Windows 测试电脑，在设备上设置防火墙规则 |
| 断网保护 (kill switch) 保持时，从启动到连接 | 21–25 秒 | 5.1–5.2 秒 | Windows 测试电脑，反复重启 |
| 在没有记忆的网络上首次连接 | 固定的模式顺序 | 1.6 秒（使用提示中的模式） | Android 测试设备 |
| API 无法访问时的连接 | 无处可连 | 点击后 12 秒即已连接 | Android 测试设备，API 被阻断，忽略缓存 |
在现场，10 月 16 日之后的几天里，Android 上的连接成功率测得在 98.3–98.6 % 之间（此前几周逐日在 80 % 到 98 % 之间波动）；Windows 2.9.8 上为 97.4 %。我们不把这一差异仅归功于 3.0：由于遥测在结构上是匿名的，3.0 分组中的设备无法与其他设备区分，而且同样的版本中还发布了其他修复。在推出期间，未见任何可归因于 3.0 的投诉或成功率下降；推出决策即依据这一标准。
6隐私
3.0 中会学习的部分不需要新的用户数据。连接遥测在结构上是匿名的：事件只以每日合计的形式写入两张没有共同行的独立表。
- 网络表：国家/地区 + ASN（来自已签名的网络令牌）、模式、结果计数。不含服务器。
- 服务器表：服务器 × 客户端所在国家/地区、结果计数。不含 ASN。
- 任何一张表中都没有账户、设备身份或 IP 地址；无法通过合并两张表追溯到某一位用户。
- 关于最近可用服务器、停滞标记和惩罚的记忆保存在设备上，不会与面板共享。
- 推出分桶由设备身份的单向摘要计算得出；不会保存哪台设备属于哪个分组。
7连续性引擎：CSL alpha
Colitu Session Layer (CSL) 就是 2.0 报告中作为未来工作提到的会话层。它的目的是：即使下层隧道发生变化，已打开的连接也不会断开：会话在多条承载通道 (lane) 上运行，一条通道失效时，会话在另一条上继续。源代码以 Apache-2.0 许可证开放：github.com/colitu/csl。
CSL 目前处于 alpha 阶段：它仅向测试账户和一台单独的测试服务器开放，入口是 Windows 应用高级模式中的“Seamless session (alpha)”选项。每台设备会生成独立的会话标识；服务器端只在本地监听。CSL 关闭或失败时，应用会回到普通连接。我们不给出面向公众开放的日期。
8局限性
- 是规则，不是模型。“预测式”启动指的是由匿名汇总数据得出的规则，而不是统计模型。数据很少的网络没有提示，沿用 2.0 的行为。
- 测量的范围。实验室结果来自一台测试电脑和一部测试手机，故障在设备上产生；没有在有真实用户的服务器上做过故障测试。不能推广到每一个网络。
- Go 引擎处于影子模式。决策仍在各应用自己的代码中；iOS 上没有该引擎。
- 在 Linux 上，网络提示和恢复集尚未启用。
- 已打开的 TCP 流在 CSL 正式开放之前，路径切换时可能中断；浏览器和应用通常会自行重新连接。
9后续步骤
- 在影子模式中的差异消除之后，把决策交给 Go 引擎；把该引擎加入 iOS。
- 把 CSL 推进到 beta 阶段：Android、UDP 数据报支持，以及面向语音和视频通话、把关键流量同时通过两条通道发送的“通话模式”。
- 自适应伪装：针对每个网络，在现有传输设置中进行选择。
- 在进一步验证后，把 Linux 纳入推出。
这些条目是路线图，而不是对日期或结果的承诺。每一项上线时，本报告都会更新。
10结论
2.0 确立了“发现路径出现故障并恢复”的原则。3.0 从三个方向对其加以扩展：借助匿名网络提示减少盲目尝试，借助恢复集和已保存的地址摆脱对 API 的依赖，以及约 11 秒即可诊断出的中断。共用测试向量确保四个应用在相同情况下做出相同的决策。连续性和伪装方面仍处于起步阶段；我们将用测量得到的结果对其进行报告。上一版本的设计和一小时故障测试见 Adaptive Connect 2.0 报告。
·参考资料
- RFC 8305, Happy Eyeballs Version 2: Better Connectivity Using Concurrency.
- RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport.
- RFC 5482, TCP User Timeout Option.
- Colitu Adaptive Connect 2.0 技术报告，2026 年 10 月 10 日。
- Colitu Lab，Adaptive Connect 故障回归测试 (faultlab)。
- Colitu Session Layer (CSL) 源代码，github.com/colitu/csl。