--- title: 从 VMess 到 VLESS：协议演进史 date: 2026-05-10 categories: - 协议与原理 tags: - VMess - VLESS - Reality - 协议 - 历史 - 演进 excerpt: 从 2015 年的 VMess 到 2023 年的 Reality，代理协议演进史。理解为什么当前推荐 VLESS+Reality。 index_img: /images/posts/vmess-to-vless-evolution.png --- > **摘要**: 从 2015 年的 VMess 到 2023 年的 VLESS+Reality+XHTTP，代理协议经历了快速演进。每一次升级都是为了应对 GFW 不断增强的检测能力。本文梳理这段演进历史，帮助你理解为什么当前推荐 VLESS+Reality。 ## 为什么要了解协议演进 很多人选择代理协议的逻辑是"别人推荐什么就用什么"。这在大部分时间没问题，但当封锁来临、节点批量失效时，不理解协议原理的用户往往无法判断问题出在哪里，也无法做出有效的应对决策。 理解协议演进的过程，本质上是理解 GFW 检测手段的进化过程。每一次协议升级都不是凭空发生的——它背后对应着一种新的封锁策略。掌握了这条时间线，你就能建立起"为什么要用这个协议"的判断框架，而不只是记住一个结论。 本文按时间线梳理从 VMess 到 VLESS+Reality 的完整演进历程，覆盖关键技术节点和社区事件。 --- ## 2015-2017: VMess 时代 2015 年，Victoria Raymond 发布了 V2Ray 项目，其核心协议 VMess（V2Ray Message Protocol）成为 Shadowsocks 之后最重要的代理协议。 VMess 的设计思路与 Shadowsocks 有根本区别。SS 追求极简——只做加密转发；而 VMess 在协议层面加入了更多功能：基于 UUID 的用户认证、自带的加密层、以及指令头的时间戳校验机制来防止重放攻击。 这一阶段的 GFW 主要依靠端口封锁和 IP 黑名单，对协议层面的识别能力有限。VMess 的设计在当时是足够安全的。 --- ## 2018-2019: Clash 与生态成熟 2018 年，Dreamacro 发布了 Clash，这个项目带来的变革不在协议层面，而在用户体验层面——它将代理从"能用"推向了"好用"。 Clash 的核心创新是基于规则的流量分流：根据域名、IP、地理位置、进程名等条件，将不同的流量路由到不同的代理节点或直连。YAML 配置文件格式让规则编写和分享变得容易。 这一时期，VMess + WebSocket + TLS 成为主流部署方案。Clash 的规则分流 + VMess/WS/TLS 的传输方案 + CDN 中转的部署架构，构成了这个时代最典型的代理方案。 --- ## 2020: VLESS 与 Xray 分裂 2020 年是代理协议发展的关键转折点，技术和社区两条线同时发生了重大变化。 **技术线：XTLS 与 VLESS 的诞生** 开发者 RPRX 提出了 XTLS 的概念。基于"TLS 之上不需要再做加密"的思路，VLESS 协议被设计出来——去掉了协议层的加密，将加密完全交给外层的 TLS；精简了协议头，减少了协议指纹；保留了 UUID 认证机制。 **社区线：[V2Fly](https://www.v2fly.org/) 与 Xray 的分裂** RPRX 从 v2ray-core fork 出了 [Xray-core](https://github.com/XTLS/Xray-core)，并以此为基础独立发展。Xray 成为 VLESS 和 XTLS 的主要载体，并逐渐在功能和性能上超越了原版 V2Ray。 --- ## 2021-2022: TLS 指纹成为焦点 GFW 开始利用 JA3/JA4 TLS 指纹来识别代理流量。Go 语言标准库的 TLS 实现产生的 JA3 指纹与主流浏览器完全不同，即使用了完美的 TLS 加密，握手阶段的指纹就已经暴露了非浏览器客户端身份。 uTLS 库的出现是对这一检测手段的直接回应。Xray-core 和后来的 [sing-box](https://github.com/SagerNet/sing-box) 都集成了 uTLS，用户只需要配置 `fingerprint: chrome` 就能模拟 Chrome 的 TLS 指纹。 Trojan 协议在这个时期经历了从崛起到逐渐边缘化的过程——它依赖真实域名和证书，带来了域名可能被封锁、证书续签可能暴露身份等运维风险。 --- ## 2023: Reality 革命 2023 年初，RPRX 发布了 Reality，同时攻克了三个长期困扰代理部署的核心难题： **第一：消除域名依赖。** Reality 通过"借用"目标网站的 TLS 证书来完成握手，不需要自己的域名和证书。 **第二：解决 TLS 指纹问题。** Reality 配合 uTLS，整个 TLS 握手过程从指纹层面看与真实访问目标网站几乎无法区分。 **第三：抵抗主动探测。** 未认证的连接会被直接转发到目标网站，返回真实响应。探测者无法区分这是代理服务器还是正常的反向代理。 Reality 的部署比传统 TLS 方案更简单：不需要购买域名、不需要申请和维护 TLS 证书、不需要运行 Web 服务器做回落。发布后迅速成为社区推荐的首选方案。 --- ## 2024-2025: XHTTP 与 AnyTLS 社区在传输层面继续探索。XHTTP 将代理数据封装为标准的 HTTP 请求，流量模式更接近正常的网页浏览行为。AnyTLS 通过在 TLS 连接内部引入填充和分片机制来扰乱流量模式。sing-box 逐步成为跨平台的主流核心。 --- ## 2026: 当前格局 **第一梯队：VLESS + Reality** —— 当前社区的首选推荐，在抗检测能力、部署便捷性、性能表现三个维度上达到最佳平衡。 **第二梯队：[Hysteria2](https://hysteria.network/)（UDP 场景补充）** —— 在 UDP 友好的网络环境中性能极为出色。推荐与 VLESS+Reality 同时部署。 **统一平台：sing-box** —— 正在成为跨平台的统一代理核心。 --- ## 演进的规律 **第一阶段：协议加密（2015-2019）** —— 核心策略是加密流量内容。局限性：加密流量本身就是一个特征。 **第二阶段：流量伪装（2019-2022）** —— 核心策略是让代理流量看起来像正常的 HTTPS 流量。突破口被 GFW 找到：TLS 指纹。 **第三阶段：身份借用（2023-至今）** —— 核心策略是借用真实网站的身份，让审查者即使进行主动探测也无法区分代理服务器和真实网站。 演进的方向始终是从"隐藏内容"到"隐藏身份"——从"让你看不懂我在做什么"变成"让你根本不知道我在这里"。 --- ## 常见问题 ### Q: VMess 彻底淘汰了吗？ 技术上已经过时，但仍有大量存量用户和节点在使用。不推荐新部署使用 VMess。如果你现有的节点还在用 VMess，建议在下次维护时迁移到 VLESS+Reality。 ### Q: 下一个革命性协议会是什么？ 几个值得关注的方向：ECH（Encrypted Client Hello）的普及、QUIC 协议的成熟、AI 驱动的流量分析。 ### Q: 我需要关心协议演进吗？ 取决于你的使用方式。使用商业机场的用户不太需要关注。个人自建的用户建议关注 Xray-core 和 sing-box 的 Release 页面。技术爱好者强烈建议深入了解。