关于 VLESS 协议的说明

我们长期收到用户关于支持 VLESS 代理协议的请求。鉴于围绕该协议存在较多争议，我们过去倾向于避免公开回应，以免引发不必要的讨论与争端。然而，持续的沉默本身也被部分解读为一种态度，甚至产生了一些误解与猜测。基于这一现实情况，我们决定对相关问题进行一次正式说明。

（由于 vless / vision / xtls 等名称本身缺乏统一且明确的定义，下文将以「VLESS」作为整个协议族的统称。）

加密代理协议社区始终保持着高度活跃。从早期的 Shadowsocks，到后来的 Trojan、ShadowTLS、TUIC、Hysteria、AnyTLS 等项目，不同开发者持续提出新的设计思路，并在开放讨论与相互借鉴中推动技术演进。许多项目均由开发者无偿投入时间与精力完成，对整个生态产生了积极影响。

因此，当新的项目具备成熟度与稳定性时，我们通常乐于进行支持与适配。尽管 Surge 本身并未直接参与开源代理协议项目，但我们与部分协议作者保持着良好的私下沟通，也会就实现细节与 issue 进行技术层面的交流。我们对此一直保持开放性态度。

然而对于 VLESS 协议，由于其设计改变了传统 TLS 的分层边界。若要实现支持，需要对上游 TLS 库（如 OpenSSL/BoringSSL）进行定制化修改，这意味着后续无法直接跟随上游更新，增加整体 TLS 子系统的复杂性与安全评估成本。

此外，XTLS 将 TLS 从传统的端到端数据保护层重新定位为一种会话引导机制，把原本由标准协议层提供的完整性保障，部分转移到应用自行定义的数据路径之上。这种跨层设计虽然带来了某些特性，但降低了安全边界的可验证性。

相比之下，Trojan、TUIC、Hysteria、TrustTunnel 等协议均建立在标准 TLS 实现之上。标准化 TLS 经过长期实践验证，是目前应用最广泛且成熟度最高的加密隧道。

事实上，针对用户的需求，我们早已完成了一份 VLESS 协议的实验性实现。然而，代码的完成并不代表产品的就绪。正如前文所述，由于该协议目前需对底层 TLS 库进行非标准修改。如果现在将其合并进主分支，意味着我们要把巨大的维护风险和潜在的不稳定性带给所有 Surge 用户，这不符合我们对产品稳定性的要求。

除此之外，VLESS 协议的特性更新非常频繁，缺乏稳定且可依赖的文档和 specification，我们对这种探索性精神表示支持，但对于产品化来说，这种频繁的变动和复杂的参数配置，将对用户体验带来巨大的挑战。

所以我们依然在观察支持 VLESS 协议的必要性，如果最终确实被广泛采纳使用，或者产生了比其他 TLS 类协议的明显优势，或者有了完整的协议 specification，我们会第一时间重新评估合并事宜。

为了避免产生更多的误解和猜疑，我们在此承诺，如果未来 Surge iOS 版本决定加入 VLESS 协议支持，将作为一项免费更新推出，所有用户均可直接使用。以此表明我们绝非因为商业原因而故意延后支持。（Surge Mac 版本用户可以通过 External Proxy Program 机制进行使用）

希望您可以理解我们的决定，我们对造成的不便感到歉意。