VLESS 与 VMess 的基础区别

VMess 是 V2Ray 的原生协议，自带一层加密；VLESS 是它的精简后继，去掉内置加密、把安全交给 TLS 层承担，开销更低。两者常出现在同一份订阅里，目前新部署以 VLESS 为主。

两个协议的来历与定义

VMess 随 V2Ray 项目于 2015 年后逐步流行，是该项目的原生传输协议。它以 UUID 作为用户身份标识，协议内部自带加密与混淆结构，每个数据单元都做加密和认证，设计上不依赖外部安全层也能保护数据。

VLESS 于 2020 年在 V2Ray 生态（及后来的 Xray 项目）中推出，定位是 VMess 的轻量化后继。它保留 UUID 验证，但移除了内置加密和大部分协议开销，明确要求与 TLS、REALITY 等外部安全层配合使用——协议自己只负责身份验证和数据转发，安全性由承载层保障。

设计差异从哪里来

VMess 诞生的年代，“协议自带一切”是主流思路：自带加密意味着即使外层不加 TLS 也不至于明文裸奔。代价是双重成本——套上 TLS 后，数据被加密了两次；协议为防重放引入了时间戳校验，客户端与服务器时间偏差过大（一般超过 90 秒）就会连接失败；早期的 alterId 机制还带来了额外的识别面，后期通过 AEAD 头部改造才得以解决。

VLESS 则是对这些历史包袱的清理：既然实践中节点几乎都套 TLS，协议层的加密就是冗余，去掉它可以降低 CPU 开销、减少特征；时间校验一并移除，连接不再受系统时间困扰。配合 XTLS/Vision 等流控技术，还能缓解“TLS 里再套 TLS”的嵌套特征问题；配合 REALITY，服务器甚至无需自有域名和证书。

关键差异对比

维度	VMess	VLESS
内置加密	有，协议层自带	无，依赖 TLS/REALITY
系统时间敏感	是（偏差约 90 秒内）	否
协议开销	较高，存在双重加密	低
典型搭配	WebSocket + TLS（利于 CDN 中转）	TCP + TLS/REALITY、Vision 流控
当前定位	存量广泛、兼容性强	新部署的主流选择

节点名称里的常见标注

订阅里的 V2Ray 系节点，名称或配置里常带一串附加标注，理解它们有助于判断节点的定位。传输方式方面：tcp 表示直接以 TCP 承载，性能最好；ws（WebSocket）表示把流量装进 WebSocket 帧，最大的价值是可以经 CDN 转发，网络环境恶劣时是重要的保底手段；grpc 与 ws 类似，同样便于经 CDN 或反向代理中转。安全层方面：tls 表示常规 TLS 加密，reality 表示使用 REALITY 方案，vision 则是配合 VLESS 使用的流控技术，用于缓解 TLS 嵌套带来的特征。

这些标注描述的是“数据怎么包装、怎么走”，与节点的物理线路无关：一个 VLESS+REALITY 节点可能走公网直连，也可能挂在专线出口上。判断体验还是要看线路本身。

实际使用中的意义

对用户来说，两类节点的日常差异主要有三处。第一，故障排查方向不同：VMess 节点集体连不上时优先检查系统时间，这是它特有的故障源，处理方式见系统时间错误导致连接失败；VLESS 没有这个问题。第二，场景搭配不同：VMess 加 WebSocket 的组合便于经 CDN 中转，在某些网络环境下是保底手段；VLESS 加 REALITY 则是当前公网直连的主流组合。第三，性能差距只在高吞吐时显现，日常浏览感知不大。

遇到订阅里两类节点并存时，可以按以下步骤取舍：

1. 对两类节点各做延迟测试，排除明显异常的节点。
2. 在晚间高峰分别试用，记录速度与稳定性差异。
3. VMess 节点异常时先校准系统时间再重测。
4. 长期使用表现更稳的一类，另一类留作备用。

常见误解

• “VLESS 不加密，所以不安全。” 它的安全模型是分层设计：验证归协议，加密归 TLS。实际部署中不存在无安全层的 VLESS 节点，数据并非明文。
• “VMess 已经被淘汰。” 它仍被广泛使用，尤其在需要 CDN 中转兼容性的场景；“不再是首选”与“被淘汰”是两回事。
• “换成 VLESS 速度就会起飞。” 协议开销只是影响速度的次要因素，线路质量才是主导，指望换协议解决高峰期拥堵并不现实。
• “同一个 UUID 泄露没关系，反正没有密码。” UUID 就是这两个协议的身份凭证，泄露等同于泄露账号，任何持有者都能使用对应节点，应与订阅链接一样妥善保管。

下一步

理解了 TCP 系协议的演进脉络后，可以对照另一条技术路线：基于 QUIC 的 Hysteria 2 如何用 UDP 思路解决高丢包问题；再结合 Shadowsocks 的轻量路线，就能完整看懂主流协议地图中每一类的位置。