tech/protocol · 集群 A · 主流协议原理 · 3/6

VMess 协议原理：时间认证、内置加密与 AEAD 头部的演进

VMess 的定位

VMess 是 V2Ray 项目最早推出的自有协议，它的设计目标是在不依赖外层安全层的情况下，也能完成用户认证并加密数据。这与后来的 VLESS 形成了鲜明对比：VLESS 选择把加密完全交给 TLS，而 VMess 选择自己做。

这种「自带加密」的设计在当时有现实意义：并不是每个部署都有域名和证书，协议内加密能保证即使没有 TLS，传输内容也不是明文。随着 TLS 部署成本下降、REALITY 等方案出现，新部署逐渐转向更精简的协议，但 VMess 仍是客户端支持最广的协议之一。

认证：UUID 与时间如何配合

VMess 认证的特点是「凭证会随时间变化」。客户端在每个请求中携带基于 UUID 与当前时间计算出的认证信息，服务端用同样的 UUID 和自己的时钟去验证，只有时间落在允许窗口内的请求才会被接受。

这样做的目的是防止重放：即使有人截获了一次请求，过了时间窗口之后再原样发送，也无法通过认证。代价是客户端与服务端必须大致对时。常见实现中允许的偏差约为 90 秒，超过这个范围就会认证失败，而且服务端通常不会返回明确的错误信息，用户看到的只是「连接超时」或「无法连接」。

VMess 节点无法连接时的检查顺序
├─ 1. 设备系统时间是否准确（开启自动对时）
├─ 2. 时区设置是否正确（时区错误同样造成时间偏差）
├─ 3. 订阅是否已更新（UUID 是否被重置）
├─ 4. alterId、加密方式是否与订阅一致
└─ 5. 以上都正常 → 转入线路与网络层排查

时间不同步是 VMess 特有的高频故障点，其他协议很少因此失败。更系统的连接故障排查思路可参考 故障排查 专题。

内置加密与算法选择

VMess 的数据部分由协议自身加密，客户端可以在配置中选择加密方式。常见选项包括 aes-128-gcm、chacha20-poly1305、auto 与 none。

这两种算法都属于现代 AEAD（带认证的加密），对普通用户而言，在它们之间比较「谁更安全」意义不大。真正需要注意的是 none：它只在外层已经有 TLS 的情况下才合理，否则数据部分将以明文传输。选择应以服务商下发的配置为准。

AEAD 头部与 alterId 的由来

alterId 是许多用户在 VMess 配置里最困惑的字段，它其实是旧版认证机制的遗留参数。早期 VMess 的请求头认证方式存在一些设计上的不足，后来协议引入了基于 AEAD 的头部认证，改善了头部的完整性与抗探测特性。

在启用 AEAD 头部的现行实现中，alterId 通常设为 0；而较老的配置可能出现非零值，表示使用旧版认证。客户端与服务端必须一致，否则无法连接。用户层面的建议很简单：照抄订阅里的值，不要自行修改。如果服务商下发的 alterId 不为 0，可以理解为该节点仍兼容旧版认证方式。

传输层组合

VMess 与 VLESS 一样可以搭配多种传输方式，最常见的是 TCP、WebSocket，以及在其外再套一层 TLS。

常见组合示意
VMess + TCP              → 结构最简单，依赖协议内加密
VMess + WebSocket        → 可经过反向代理或 CDN
VMess + WebSocket + TLS  → 增加证书校验，流量形态接近 HTTPS

在 VMess + TLS 的组合中，数据实际上被加密了两次：一次是 VMess 协议内加密，一次是 TLS。这在 CPU 开销上略有浪费，也是 VLESS 设计时去掉协议内加密的直接原因。关于 TLS 本身，可参考 代理协议中的 TLS；关于 VLESS 的精简设计，可对照阅读 VLESS 协议是什么。

从 VMess 到 VLESS：设计取舍的变化

VMess 与 VLESS 的差异，本质上反映了代理协议设计思路的转变：从「协议自己负责一切」转向「专注认证与寻址，安全交给成熟的标准层」。

VMess 诞生时，自带加密能让部署不依赖证书，降低了门槛；时间认证能在没有 TLS 的情况下抵御重放。但这套机制也意味着更多的计算开销、更多的配置字段，以及时钟依赖这一额外的故障来源。当 TLS 部署变得普遍、证书获取成本大幅下降之后，在 TLS 内部再做一遍加密就显得冗余。

VLESS 正是在这个背景下出现的：它去掉了协议内加密与时间认证，只保留 UUID 与目标地址，把机密性和完整性交给 TLS 或 REALITY。这样做换来的是更少的开销与更简单的配置，代价是失去了「裸跑也有加密」的能力。理解这一取舍，有助于判断订阅里出现的不同协议节点各自的定位，而不是简单地认为某一方更好。

什么情况下会遇到 VMess

在机场场景中，VMess 节点通常出现在需要兼顾旧客户端的订阅里，或者服务商长期沿用的部署中。原版 Clash 内核、Shadowrocket、v2rayNG、mihomo、sing-box 等客户端基本都支持 VMess，这使它成为一种「兼容性兜底」的选项。

本站品牌库中，资料标注协议的品牌均为 VLESS，没有品牌资料标注 VMess；微风网络、飞猫云、星岛梦、灵猫网络、极连云的协议资料待核实，本站不推测它们是否提供 VMess 节点。如果你的客户端较旧、只支持 VMess 等协议，选购前应先确认目标服务商实际提供的协议类型，相关判断方法见 机场协议待核实意味着什么。

小结

VMess 的设计重点是「协议自己负责安全」：时间相关的认证防止重放，内置 AEAD 加密保护数据。它带来的使用成本主要是时钟依赖与较多的配置字段。遇到 VMess 连接问题，先对时、再核对 alterId 与加密方式，通常能解决大部分配置类故障。

想按协议字段筛选或比较品牌，可以前往 机场品牌库 与 对比工具；协议之间的整体差异，可回到 代理协议 专题总览。