本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

Why a VPN’s “Connected” Status Isn’t Enough: Building Adaptive Protocol Fallback

成功的连接握手并不总是意味着互联网连接正常。在受限或不稳定的网络上，VPN 隧道可能看起来已成功建立，但实际流量却从未到达目的地。对于构建连接工具的开发人员来说，这带来了一个有趣的工程问题：你如何确定连接是否真的有效，而不仅仅是确定它是否已连接？这是我们在开发 Colitu 时正在解决的问题之一，Colitu 是一个专为挑战性网络环境设计的开源 VPN 项目。

The Problem With Trusting a Handshake

信任握手的弊端

考虑一个典型的连接序列：客户端联系远程服务器。协议握手成功。应用程序报告连接已建立。用户尝试加载网站。什么也没有发生。网络过滤器可能会允许初始握手，但会干扰后续流量。另一个网络可能会阻止 UDP，同时允许某些 TCP 连接。从应用程序的角度来看，即使连接没有用处，它看起来也可能是健康的。这就是为什么必须将连接建立和实际连通性视为独立状态的原因。

Different Networks Require Different Transports

不同的网络需要不同的传输方式

没有一种传输协议能在所有环境中同样出色地工作。Colitu 支持跨多个协议族的五种连接模式：

• Hysteria2：一种基于 QUIC 的传输协议，旨在实现高效通信，即使在具有挑战性的网络条件下也是如此。
• VLESS Reality：一种传输配置，旨在使连接更能抵御某些形式的网络过滤。
• VLESS XHTTP：一种基于 HTTP 的传输方法，在其他连接方法中断时提供替代方案。
• Trojan：一种基于 TLS 的代理协议，提供另一条加密连接路径。
• Shadowsocks 2022：一种采用现代加密机制设计的加密代理协议。 每种模式都有其自身的特点、优势和局限性。目标不是宣布某种协议在普遍意义上更优越，而是使连接选择能够响应真实的网络状况。

Introducing Adaptive Connect

引入自适应连接 (Adaptive Connect)

手动切换协议可能会令人沮丧，尤其是对于不熟悉网络技术的用户而言。Colitu 的自适应连接系统旨在降低这种复杂性。应用程序无需用户亲自排查每次连接失败的原因，而是可以在所选方法失败时尝试其他连接模式。

How the Process Works

工作流程

从宏观层面来看，自适应连接管理遵循以下步骤：

1. 服务器选择：获取可用的服务器配置。
2. 协议选择：选择兼容的连接模式。
3. 连接尝试：尝试建立加密连接。
4. 连通性验证：检查真实网络流量是否可以通过。
5. 成功：继续使用有效的连接模式。
6. 回退 (Fallback)：如果验证失败，尝试另一种可用模式。 重要的区别在于，仅凭成功的握手并不足以作为可用连通性的充分证据。

Why Connectivity Verification Matters

为什么连通性验证很重要

VPN 客户端应区分几种可能的状态：

• 已断开 (Disconnected)：未建立活动连接。
• 正在连接 (Connecting)：客户端正在尝试建立连接。
• 已连接 (Connected)：所选隧道已建立。
• 连通性已验证 (Connectivity Verified)：流量已成功通过预期的连接路径。
• 连接失败 (Connection Failed)：连接或其验证失败。 这些区分使连接处理更容易理解，也有助于开发人员避免给用户造成连接正常的错觉。

The Challenge of Protocol Fallback

协议回退的挑战

回退在理论上听起来很简单：如果协议 A 失败，则尝试协议 B。在实践中，实现可靠的回退需要做出多项工程决策：

1. 正确检测故障：超时并不总是意味着永久性故障。临时丢包、高延迟、DNS 解析问题和服务器过载都可能产生类似的症状。良好的回退策略必须在响应速度与避免不必要的协议切换之间取得平衡。
2. 选择下一个协议：不同的网络表现不同。例如，某些网络限制 UDP 流量，另一些网络干扰特定的 TLS 连接模式。某些环境允许初始连接，但会中断持续流量。网络状况可能会在应用程序运行时发生变化。回退系统应考虑这些差异，而不是假设每次连接失败的原因都相同。
3. 避免无限重试循环：重复尝试相同的失败连接模式会浪费时间和资源。重试限制、超时处理和故障状态管理是弹性连接系统的重要组成部分。
4. 管理平台差异：VPN 应用程序在 Windows、Linux、Android 和 iOS 上与不同的网络 API 交互。连接编排、路由、隧道管理和后台执行限制在不同平台之间可能存在很大差异。自适应设计必须考虑到这些差异。

Security Must Remain a Priority

安全必须始终是优先事项

可靠性绝不能以牺牲用户安全为代价。VPN 不应仅仅因为加密隧道失败就静默回退到未受保护的直接连接。这在受限网络环境中尤为重要。连接恢复应保留应用程序的安全保证，并向用户提供准确的状态信息。失败的安全连接优于未通知的保护丢失。

What Adaptive Fallback Cannot Solve

自适应回退无法解决的问题

自适应连接很有用，但它不是万能的解决方案。它存在局限性：网络可能会阻止所有可用的传输方式；强制门户 (Captive portals) 可能需要额外的身份验证；某些网络可能会在不考虑协议的情况下中断加密流量；尝试多种连接模式可能会增加初始连接时间。