VMess 与 VLESS 有什么不同：时间校验与加密层的差别

两者的根本差别：谁负责加密，认证靠不靠时间

VMess 与 VLESS 都来自 V2Ray 与 Xray 社区，都用 UUID 识别用户，但分工不同：VMess 在协议层自己加密，并把时间纳入认证，客户端与服务器时间相差过大就会认证失败；VLESS 去掉了协议层加密和时间依赖，只做认证和寻址，加密交给外层的 TLS 或 REALITY。两者的选择通常由机场决定，用户需要关心的是这两点差别会在什么情况下表现为连接故障。

本文只比较两个协议本身，故障排查操作归客户端专题。所属二级专题见 代理协议二级专题，协议总览见 线路协议专题。

逐项对照

表中最容易在使用中“现形”的，是时间依赖和加密层两行。

时间校验：为什么 VMess 怕时钟不准

VMess 的认证信息由 UUID 和当前时间共同生成，服务器收到后，用自己的时间推算一个允许范围，只有落在范围内的请求才被接受。按 V2Ray 文档的说明，客户端与服务器的实际时间差需要控制在约 90 秒以内。这个设计的目的是防重放：即使有人录下了一段合法请求，过一段时间后再发送也会失效。

需要澄清两点常见误解：

• 时区不重要，时刻才重要。 认证用的是统一的标准时间，设备显示北京时间还是其他时区不影响；但如果设备的实际时刻慢了几分钟，就会失败。
• 症状往往是“全部 VMess 节点同时失效”。 因为问题出在本机时间，换哪个节点都一样；而同一订阅里的其他协议节点可能仍然正常。

VLESS 没有这一依赖，这是它在实际使用中更“省心”的地方。不过要注意，外层的 TLS 证书校验、REALITY 认证和 Shadowsocks 2022 也会用到时间，时钟严重偏差时仍可能出问题，只是容忍范围和表现不同。时间故障的具体处理见 系统时间不准导致节点连不上的原因。

加密层：一次还是两次

VMess 自带加密，常见选项包括 AES-128-GCM、ChaCha20-Poly1305，以及由客户端自动选择的模式，也可以设置为不加密。当 VMess 外面再套一层 TLS 时，数据实际上被加密了两次：协议层一次，TLS 一次。这在安全上收益有限，却增加了计算开销，在性能较弱的设备上更明显。

VLESS 的思路是只保留一层：既然外层 TLS 已经足够，协议层就不再重复。代价是 VLESS 不能脱离外层安全单独暴露在公网上，否则 UUID 和目标地址都会以明文出现，原因见 VLESS 为什么本身不加密。

认证方式的演进与 alterId

VMess 的认证方式本身也经历过一次更新。旧版认证使用额外的 ID 列表，参数里的 alterId 大于 0 即表示旧版；新版采用基于 AEAD 的认证头，要求 alterId 为 0。新版修正了旧版的一些弱点，目前主流实现默认使用新版，部分客户端已不再接受旧版配置。

因此，导入 VMess 节点时，如果看到 alterId 不为 0，又遇到连接失败，可能是客户端与服务器对认证方式的预期不一致。这类问题在 VLESS 上不会出现，因为 VLESS 从一开始就没有这个历史包袱。

不同场景下差别是否重要

两者的差别并不会在每个人身上都表现出来，可以按场景粗略判断：

可以看出，差别主要体现在“出问题时”而不是“正常使用时”。这也是本站不把协议名称当作速度或质量依据的原因。

在节点参数上怎样区分

导入订阅后，可以从以下几处区分一个节点是 VMess 还是 VLESS：

1. 分享链接的开头。 一种以 vmess:// 开头，一种以 vless:// 开头。VMess 链接的主体常常是一段 Base64 编码的配置，VLESS 链接则把参数直接写在网址的查询部分。
2. 配置文件里的类型字段。 Clash 系配置里，类型字段分别写为 vmess 或 vless。
3. 特有参数。 出现 alterId 或可选加密方式的是 VMess，出现流控参数的是 VLESS。

本站整理的 17 个品牌资料中，12 个写明 VLESS，没有品牌把 VMess 写为主要协议，5 个协议待核实。资料写 VLESS 不排除订阅里同时存在 VMess 节点，具体以导入后看到的节点类型为准。

遇到问题时先分清是哪一层

如果只有 VMess 节点失效、VLESS 节点正常，优先怀疑本机时间或 alterId；如果两类节点同时失效，问题多半在外层 TLS、订阅或网络本身，不在协议差异上。具体的排查顺序属于客户端操作，见 规则分流与故障排查。术语含义可在 常用术语表 中查阅。

请遵守所在地法律法规与平台条款，本文不提供规避监管的方法。