主题
VMess 与 VLESS 有什么区别：V2Ray 系协议的演进与选择
VMess 和 VLESS 是同一个技术家族的两代协议：VMess 是 2015 年前后随 V2Ray 项目诞生的原生协议，自带加密与认证；VLESS 则是后来在 Xray 生态中发展出的精简版本，把加密交给外层的 TLS 处理，自身只负责身份验证与转发。在机场订阅里，它们常与 Shadowsocks、Trojan 并列出现，是当前主流代理协议中演进十分活跃的一支。
工作原理
VMess 的认证围绕一个 UUID（可以理解为一长串随机生成的「用户编号」）展开：客户端用 UUID 与当前时间戳计算出认证信息，服务器据此判断请求是否来自合法用户。引入时间戳是为了对抗重放攻击，但也带来一个副作用——时间敏感性。协议默认只容忍约 90 秒的时间偏差，一旦设备系统时间与标准时间相差过大，服务器会直接拒绝连接。不少「VMess 节点全部超时、换台设备却正常」的案例，根源就是系统时间不准，这类问题可参考连接超时类故障排查。
VLESS 走的是做减法的路线。设计者认为，既然现代部署几乎都会在外层套一层 TLS 加密，协议内部再加密一次属于重复劳动，于是 VLESS 去掉了内置加密与时间校验，只保留 UUID 认证，结构更简单、开销更低。代价是它不能「裸奔」，必须与 TLS 等加密传输层搭配使用。在此基础上，Xray 生态又发展出 Reality 技术：服务器无需持有自己的域名证书，而是在握手阶段「借用」某个知名网站的 TLS 特征，让探测者看到的证书信息与真实大站一致，从而缓解了传统 TLS 伪装中证书容易暴露服务器身份的问题。
主要特点
- VMess：功能完整，历史包袱也多。早期的 alterId 混淆设计已被 AEAD 认证取代，如今配置中该值普遍为 0。它可以脱离 TLS 独立工作，但那样流量特征明显，实际部署仍以搭配 TLS 或 WebSocket 传输为主。
- VLESS：轻量、靠组合取胜。协议本身极简，性能开销低，配合 XTLS、Reality 等技术时在伪装与效率上表现较好，是近年新搭建服务中出现频率较高的选择。
- 共同点：都以 UUID 作为身份凭证，都支持多种传输层组合，节点参数较多。好在这些细节由订阅自动下发，用户一般无需手动处理。
适用与不适用的场景
如果订阅里两类节点都有，日常使用差别不大；网络环境敏感的时期，可优先选择带 Reality 或 TLS 的 VLESS 节点，伪装性通常更好。VMess 适合作为兼容性备选——一些老客户端只认识它。反过来看，系统时间经常漂移的设备（如部分电视盒子）使用 VMess 容易莫名断连；而 VLESS 节点在老旧客户端上可能无法导入，需要先升级软件。
客户端支持情况
Mihomo（即 Clash Meta）内核对 VMess、VLESS 及 Reality 均有支持；但早已停止更新的原版 Clash 内核不认识 VLESS，遇到「节点导入后凭空消失」多半是内核过旧。iOS 的 Shadowrocket 对两者支持完善且跟进较快；sing-box 支持完整；v2rayN 直接使用 Xray 内核，与这两种协议同出一脉，兼容性自然可靠，Windows 用户可参考 v2rayN 使用教程上手。选购服务时不必刻意追求某一协议，节点类型丰富、内核适配及时的机场更省心，可参考机场推荐榜单。
常见误区
- 「VLESS 不加密，所以不安全」：VLESS 只是不在协议层重复加密，实际流量由外层 TLS 负责加密，安全性并不因此打折扣。
- 「VLESS 是升级版，VMess 该淘汰了」：两者定位不同，VMess 仍被大量服务正常使用，谈不上淘汰，只是新部署更多转向 VLESS。
- 「Reality 节点不会被识别」：Reality 显著提高了探测成本，但攻防是动态演进的，把任何单一技术当作一劳永逸的保险都不现实。
FAQ
为什么我的 VMess 节点全部连不上，VLESS 却正常？ 优先检查设备系统时间与北京时间的误差是否在一分钟以内。VMess 校验时间戳而 VLESS 不校验，这是两者表现分化的常见原因。
UUID 需要自己生成吗？ 不需要。机场在服务端为每位用户分配 UUID 并写入订阅，客户端导入后自动使用。
V2Ray 和 Xray 是什么关系？ Xray 是 2020 年从 V2Ray 分叉出的项目，兼容其大部分功能；VLESS、XTLS、Reality 主要在 Xray 生态中发展。日常使用无需细究，客户端会处理好兼容性。
节点名里的 WS、gRPC 又是什么？ 那是传输层方式（WebSocket、gRPC 等），可以理解为数据「搭乘的交通工具」，与 VMess/VLESS 这类「乘客身份」属于两个维度，常见组合已由服务商调配好。