Colitu Adaptive Connect 2.0 与热备用：技术报告

#摘要

有些网络会阻断 VPN 协议；另一些网络的行为则更为隐蔽：它们允许连接建立，然后在几十秒后悄悄停止传输流量。在这样的网络上，“能响应 ping”与“能传输流量”并不是一回事。本报告介绍 Colitu 应用针对这一问题所采用的一整套机制，即 Colitu Adaptive Connect 2.0：兼顾就近原则与隐私的服务器排序、仅保存在设备上的按网络记忆、由匿名计数器得出的网络提示、基于真实流量的连接时健康检查、服务器回退、在运行中的连接内保持就绪的热备用，以及覆盖所有传输方式的会话中监测。评估是在一部 Android 手机上、一个家庭 Wi-Fi 网络中进行的，该网络位于一个实施深度包检测 (DPI) 的国家，故障仅针对这一个客户端在服务器端注入。在最佳配置下，当主路径被切断 120 秒时，VPN 保持开启，没有重新连接，中断持续约 5–10 秒。在一次 60 分钟的耐久测试中，在 8 台服务器上注入了 11 次故障，通过隧道的探测有 98.8 % 成功；当正在使用的服务器被完全切断 101 秒时，用户只感受到约 5 秒的停顿，VPN 保持开启。局限性以及尚未测量的情形另行列出。

#1. 引言

1. 1
   VPN 应用的首要任务是以正确的连接模式连接到正确的服务器。Colitu 服务器提供来自四个协议家族的五种连接模式：Hysteria2 (UDP/QUIC)、VLESS Reality、VLESS XHTTP、Trojan 和 Shadowsocks 2022（请参阅技术细节）。
2. 2
   传统做法是按 ping 对服务器排序，并选择响应最快的一台。但 ping 只是一个提示：在某些网络上，服务器会响应 ping，却完全无法传输流量。
3. 3
   还有一种更棘手的情况：连接建立了，应用显示“已连接”，但过了一段时间流量停止，而 TCP 连接看上去仍然是打开的。对用户来说，这意味着 VPN 开着，但互联网却用不了了。
4. 4
   Adaptive Connect 1.x 解决了其中一部分问题，但我们的测量显示出两个重要缺口：服务器列表按数据库 id 顺序排列，并且会话中监测只覆盖 Hysteria2（见第 4 节）。
5. 5
   Adaptive Connect 2.0 的目标是：在连接时找到真正可用的路径，察觉已连接状态下失效的路径并将用户转移到另一条路径（尽可能不关闭 VPN），并且在做到这一切的同时不收集关于用户的信息。

#2. 威胁与故障模型

设计考虑了以下几类故障。它们基于在某些网络和某些移动运营商处观察到的行为，而不针对任何特定国家。

假设：

1. 1
   一个网络可能阻断某种模式而另一个网络不阻断，因此“可用”是网络的属性。
2. 2
   一个网络可能把同一台服务器的所有 TCP 模式一并冻结；此时同一服务器上的另一种 TCP 模式作为备用毫无用处。
3. 3
   设备自身的互联网可能中断；此时不应归咎于任何模式。

#3. 设计

下列机制是为 Windows、Linux、Android（包括电视）和 iOS 应用设计的。所有机制在每个应用中都相同。第 4 节中的测量是在一部 Android 手机上进行的。

3.1 服务器排序

1. 1
   用户选择的位置按原样使用。Colitu 绝不会自行更改手动选择。
2. 2
   在自动模式（“最快服务器”）下，顺序如下：

1. 1
   服务器列表中的“推荐”始终显示自动模式将要连接的服务器。
2. 2
   隐私： 为了对列表排序，面板仅根据该请求的 IP 地址推算出您所在的国家/地区和互联网服务提供商的网络。不会存储任何内容。当请求经由 VPN 到达时，面板无法得知这些信息，应用会保留最近一次获知的值。

3.2 按网络记忆

1. 1
   “网络”是连接类型（Wi-Fi、移动数据、以太网）与您的互联网服务提供商的网络的组合。家庭 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 上，自动重试会沿着列表向下，而不是重试同一台服务器。
4. 4
   如果在手动选择的服务器上所有模式都失败，错误提示会提供一键“尝试最快服务器”。

3.6 热备用

拓扑。 已连接时，应用在运行中的连接内保持第二条路径就绪。流量经过一个均衡器：主路径健康时，所有流量都走主路径；如果主路径停止工作，新的流量会自动转移到备用路径。VPN 保持开启，不会出现“正在重新连接”的界面。由于切换发生在连接内部而不是应用界面中，因此应用处于后台时同样有效。备用路径仅在被使用时才会连接。

选择备用路径。

在此网络上失败过的模式和服务器绝不会被选作备用路径。

前缀陷阱。 在 Xray 中，均衡器和观测器的选择器是按前缀匹配标签的。如果备用路径的标签与主路径的标签以相同前缀开头，观测器就会把备用路径也当作主路径。因此，备用路径的标签被选为与主路径没有任何共同前缀。

DNS。 来自 Xray DNS 模块的查询有一条指向均衡器的明确规则。

TCP 用户超时。 连接备用路径后，TCP 路径使用 10 秒的 TCP 用户超时（概念来自 RFC 5482），这样失效的连接会被关闭，而不是一直挂起。

检测时间和开销。

Windows 断网保护也会放行备用服务器；Linux 会将其加入允许列表。备用路径的配置与连接并行获取，绝不会延迟连接，并且会被缓存。热备用默认开启；可以在高级模式中关闭，在简单模式中始终开启。

3.7 会话中监测与感知备用路径的规则

1. 1
   在 Adaptive Connect 1.x 中，会话中监测只覆盖 Hysteria2。在 2.0 中，所有传输方式都会被监测。
2. 2
   频率：前 90 秒内每 5 秒一次，之后每 30 秒一次。设备在线的情况下连续三次未响应，即视为主路径已失效。
3. 3
   感知备用路径的规则。 连接备用路径后，监测器会分别检查两件事：仅主路径，以及常规路径（均衡器所使用的路径）。

1. 1
   这条规则修复了第 4 节实验 1 中发现的缺陷：旧的监测器在备用路径正在承载流量时重启了连接，并导致连接中断。
2. 2
   Android 和 iOS 在意外中断后会自行重新连接（约在 2 秒、5 秒和 15 秒后，之后显示错误），并在网络恢复时再次重连。在您点击断开连接、退出登录，或套餐或设备被暂停之后，则不会重连。

3.8 不会锁死网络的停滞标记

错误的停滞标记可能让某个网络上没有任何模式可以尝试。两条规则可防止这种情况：

1. 1
   如果这些标记会导致所提供的传输方式只剩不超过一种，则在这一轮中忽略它们。
2. 2
   在一轮全部失败的尝试中发现的标记，保留 10 分钟。仅当随后有另一种传输方式在同一网络上承载了流量时（也就是问题确实只针对该模式时），才适用 6 小时的保留期。

3.9 节点在线上报与负载

每次心跳时，服务器会上报不同的已连接用户数（Xray 的在线用户统计和 Hysteria2 的在线接口）。面板只使用完整的上报；如果无法读取某个核心的统计，则保留先前的值。因此，已满的服务器不再被推荐，基于负载的分配也使用真实数字。这些上报已在所有服务器上生效。

3.10 备用路径健康探测与并行连接

以下两种机制已包含在所有应用中；两者在 4.3 的耐久测试中均处于启用状态：

1. 1
   备用路径健康探测。 备用路径也会通过其自己的检查入口大约每分钟检查一次。失效的备用路径只会在隧道空闲时被替换，绝不会在通话期间替换。
2. 2
   并行连接（“happy eyeballs”）。 同时检查最好的两个候选项，最先成功承载流量的一个胜出。该思路借鉴了 RFC 8305 的 Happy Eyeballs 方法。

#4. 评估

4.1 方法

为此编写了一个内部工具（故障实验室）：它使用带标记的防火墙规则，为一个客户端切断一个协议（在所有列出的服务器上）或一整台服务器，通过自动删除的定时器移除规则，每 5 秒探测一次客户端并持续一小时，并按故障报告中断时长。在 4.2 的热备用实验中，故障逐个施加；在 4.3 的耐久测试中，该工具在 60 分钟内以随机顺序注入故障。

4.2 结果

排序。 用户所在国家/地区的一台服务器 ping 最低（13–15 ms），但被正确地排在附近一台国外服务器（16–17 ms）之后。在 Adaptive Connect 1.x 中，列表按数据库 id 顺序排列，另一个大洲上约 222 ms 的服务器被显示为“推荐”。

冻结观察。 在这个网络上，到附近一台服务器的每一种 TCP 传输方式（VLESS Reality、VLESS XHTTP、Trojan）都在连接后约 30–50 秒冻结：流量停止，而 TCP 保持打开。Hysteria2 持续可用。只覆盖 Hysteria2 的旧监测器在这种情况下显示“已连接”，却没有流量。新的覆盖所有传输方式的监测器检测到了冻结，并在约 1.3 秒内切换了传输方式。

基线。 已发布的 2.7.0 版本在同一网络上使用 Hysteria2 不间断运行了 100 秒。

热备用实验（仅针对该客户端，在服务器上丢弃主路径的数据包）：

4.3 耐久测试

2026 年 10 月 10 日，在同一部手机和同一个 Wi-Fi 网络上，使用包含全部 2.0 机制（包括备用路径健康探测和并行连接）的 Android 构建，在自动模式下进行了一次 60 分钟的耐久测试。

1. 1
   方法。 故障实验室在 8 台服务器上以随机顺序注入了 11 次故障，故障之间间隔 2–5 分钟，每次故障持续 60–120 秒。使用了两种故障类型：针对该客户端在每台服务器上切断一个协议，以及针对该客户端完全切断一台服务器。
2. 2
   探测。 每 5 秒通过隧道发出一次 HTTP 请求。
3. 3
   结果。 750 次探测中有 741 次成功（98.8 %）。

解读。

1. 1
   故障 3 是关键案例： 正在使用的服务器消失了 101 秒；用户感受到约 5 秒的停顿，VPN 保持开启。
2. 2
   故障 11： 在这个网络上，每一种 TCP 协议都被 DPI 冻结。在所有地方切断 Hysteria2 之后，不存在任何可用协议；故障结束 2 秒后流量恢复。
3. 3
   针对未使用的协议和服务器的故障如预期显示为 0 秒：其他位置的故障不会干扰当前会话。

局限。 一台设备、一个网络、一小时；故障是在服务器端注入的，而不是由真实的审查系统造成的。

所测试的机制在所有应用（包括电视在内的 Android、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
   出口轮换。 此功能会强制在一台服务器上使用 VLESS，并禁用热备用。在被测网络上，这意味着反复冻结。这是一项已记录的局限。
2. 2
   未完成的 TCP 流。 切换到备用路径期间，通话会在短暂卡顿后继续，页面和消息会自行重新连接；但此刻正在进行的大文件下载可能会重新开始。真正无缝地继续下载是未来的工作。
3. 3
   单一设备、单一网络、一小时。 评估使用了一部 Android 手机、一个网络，测试时长至多一小时；故障是在服务器端注入的，而不是由真实的审查系统造成的。结果不能推广到其他网络。
4. 4
   过时的网络键。 VPN 开启时，面板无法看到请求来自哪个网络；应用会使用它最近一次获知的网络，直到在 VPN 关闭时再次获取列表。
5. 5
   在线计数。 通过 sing-box 连接的用户不包括在在线上报中；同时连接到两台服务器的用户在总数中会被计算两次。
6. 6
   无备用路径。 多跳路线和单一模式的服务器上没有热备用。sing-box 无法运行 XHTTP。

#6. 未来工作：CSL 会话层

Colitu 会话层 (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 秒的间隙。我们还在考虑在高级模式中提供一项可选的“强制 QUIC 改用 TCP”设置。
5. 5
   没有 CSL 时。 如果服务器上的开关关闭、CSL 没有响应，或返回“繁忙”或“拒绝”，客户端会在几秒钟内回到现在的路径。没有载体超过 90 秒的会话将会丢失。看门狗会关闭卡住的 CSL 客户端。
6. 6
   用户如何获得。 以“无缝会话（测试版）”的形式出现在高级模式中；默认关闭，并且仅在开关已开启的服务器上显示。

#7. 结论

Adaptive Connect 2.0 的核心经验是：决定一条路径是否可用的是真实流量，而不是 ping，并且这一判断取决于网络。兼顾就近原则与隐私的排序、保存在设备上的网络记忆、匿名网络提示，以及只测量主路径的健康检查，使得找到正确的路径成为可能。已连接时，热备用加上覆盖所有传输方式并知晓备用路径的监测器，把主路径被切断的情形变成了约 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 project documentation.
5. 5
   Xray-core project documentation.