VMess 与 VLESS 都是 V2Ray 生态里的传输协议，差别集中在身份验证字段、是否内置加密、加解密开销与客户端内核要求四点。本文按这四点逐项对照，并给出自建服务端与使用他人订阅两种场景下的选型判断。
身份验证：同一个 UUID，VMess 多一个 alterId
两个协议都用 UUID 标识用户身份。服务端在 clients 数组里写死一串 UUID，客户端配置里的 id 必须逐字符一致，差一个字符就是认证失败。单看这一点，VMess 与 VLESS 没有区别。
差异来自 VMess 早期多出的 alterId 字段。它由 UUID 派生出一组临时标识，配合时间戳抵抗重放攻击，旧版默认值 64。代价是客户端与服务端的时间差必须控制在 90 秒以内，系统时间漂移或跨时区使用时经常因此连不上。
| 对照项 | VMess | VLESS |
|---|---|---|
| 身份字段 | UUID + alterId（旧版） | 仅 UUID |
| 防重放机制 | alterId 派生标识 + 时间戳；AEAD 后由协议自身保证 | 交给传输层 |
| 时间同步要求 | alterId > 0 时需与服务端时间差在 90 秒内 | 无要求 |
| 新版配置 | alterId 填 0 | 无该字段 |
2022 年 1 月发布的 V2Ray v4.35 把 alterId 标记为废弃，v5 直接移除该字段。现在 v2rayN 6.x 新建 VMess 节点，alterId 默认就是 0，走 AEAD 认证，不再校验时间戳。只要两端都填 0，这一条差异就基本被抹平。
VLESS 从设计之初就没有 alterId，防重放交给传输层处理，服务端不需要维护会话状态，协议头也更短。所以第一点可以总结成一句话：新版本里两者一样简单，只有遇到 alterId 非 0 的旧节点时才需要额外留意时间同步。
传输层依赖：VLESS 不做二次加密
VMess 协议自带加密层。即使不套 TLS，VMess 流量本身也是加密的，配置里的 security 字段可以填 auto、aes-128-gcm、chacha20-poly1305 或 none。这让它可以裸跑 TCP，也可以搭配 mKCP 这类不依赖 TLS 的传输方式。
VLESS 反过来：协议本身只做认证和转发，一个字节都不加密，配置里固定写 "encryption": "none"，负载明文交给传输层。裸跑 TCP 的 VLESS 等于明文传输，实际部署必须套 TLS、XTLS 或 REALITY。
{
"outbounds": [{
"protocol": "vless",
"settings": {
"vnext": [{
"address": "node.example.com",
"port": 443,
"users": [{
"id": "b831381d-6324-4d53-ad4f-8cda48b30811",
"encryption": "none",
"flow": "xtls-rprx-vision"
}]
}]
},
"streamSettings": {
"network": "tcp",
"security": "reality"
}
}] // VLESS 出站：加密交给 REALITY 传输层
}注意
节点信息里没有 TLS、REALITY、XTLS 字样时，先确认传输层是否安全。VLESS 自身不提供加密兜底。
常见的 VLESS 部署组合有三类：
- VLESS + TCP + TLS：443 端口，最简部署，需要自有域名与证书
- VLESS + XTLS Vision + REALITY：Xray 内核支持，不需要自备域名和证书
- VLESS + WebSocket + TLS：走 CDN 中转时使用，与 VMess 的同类组合结构一致
REALITY 与 XTLS Vision 目前只有 VLESS 有对应实现，VMess 没有。节点信息里出现 flow: xtls-rprx-vision 或 security: reality，那它一定是 VLESS。
加密开销：双层与单层的实际差别
把差异换算成 CPU 开销更直观：VMess 走 TLS 时是两层加解密——外层 TLS 一次，协议内置一次；VLESS 只有外层 TLS 一次。每一次加解密都要占用 CPU 周期，连接数越多，差距越明显。
这个差别在什么设备上能感知？桌面端现代处理器基本测不出来；单核低配服务器、老款手机或路由器上，VLESS 省下的那层开销会体现在连接数与吞吐上。
结论：换协议之前先看设备
桌面端与正常网络下，VMess 和 VLESS 的速度差在测量误差范围内；只有当设备性能吃紧或并发连接数高时，VLESS 省掉的这层加解密才值得作为切换理由。
客户端兼容性：内核版本决定能不能用 VLESS
VLESS 能不能用，取决于客户端内置的内核版本。v2rayN 6.x 默认使用 Xray 内核，VMess 与 VLESS 全系支持；v2rayNG 同样基于 Xray 内核；v2flyNG 使用 v2fly 内核，从 v4.27 起支持 VLESS，但不支持 REALITY。
Xray 内核
推荐v2rayN 6.x 默认内核、v2rayNG 使用。VLESS 与 XTLS Vision、REALITY 全支持，VMess 也完整兼容。
适合：新装客户端、要用 REALITY 节点
v2fly 内核
v2flyNG 使用。v4.27 起支持 VLESS，REALITY 不在支持范围内，VMess 与 WebSocket 兼容性稳定。
适合：只用 VMess 与 WebSocket 的存量节点
版本号是硬门槛。V2Ray 内核 v4.26 及以前不认 vless:// 链接，订阅里混入 VLESS 节点时导入会直接失败。查看方式：v2rayN 主界面「设置」→「参数设置」→「Core: 基础设置」，Xray 内核版本号是 1.x，v2fly 内核是 4.x 或 5.x。
分享链接的前缀也能用来区分：vmess:// 后面是 base64 编码的 JSON，vless:// 是 URI 查询串形式，形如 vless://uuid@地址:端口?参数#备注。一条订阅里两种链接可以混存，客户端按前缀分别解析，节点列表里只是多几条记录。
结论：协议跟着服务端走
节点用什么协议在服务端就定死了，客户端能选的只有内核与传输方式。拿到 VMess 节点照用即可，不需要为了「更新」去转换。
什么时候需要在意
把四个对照点落到日常使用，真正需要在意协议差异的场景只有三类。
按场景选型：新部署走 VLESS，存量节点保持原样
自建服务端
- Xray 内核 + VLESS + REALITY
- 端口 443，flow 填 xtls-rprx-vision
- 不需要自备域名与证书
使用他人订阅
- 服务端给什么协议就用什么协议
- VMess 节点无需转成 VLESS
- alterId 一律填 0
协议在服务端定死，客户端改不了；一条订阅里两种节点混存不会互相影响。
剩下两类的判断更直接：设备性能吃紧时优先 VLESS，少一层加解密；需要 CDN 中转或兼容旧客户端时，VMess + WebSocket + TLS 的适用面更宽。
订阅里同时有 vmess:// 和 vless:// 链接，会冲突吗？
不会。客户端按链接前缀分别解析，一条订阅里两种节点可以共存，节点列表里只是多几条记录。
VLESS 节点连不上，日志提示 invalid user 是什么原因？
UUID 不匹配。核对客户端 id 与服务端 clients 里的 UUID 是否逐字符一致，或重新更新一次订阅。
VMess 的 alterId 到底填多少？
新版一律填 0。v2rayN 6.x 新建节点时默认就是 0；订阅里返回非 0 值说明服务端内核较旧，两边保持一致即可。
换成 VLESS 会更快吗？
协议不决定速度，线路质量占大头。VLESS 省掉一层加解密，在低配设备上有可感知差别，桌面端正常网络下差距很小。
协议是服务端与客户端之间的约定，不是可以随手切换的开关。分清这四点差异，足够应付日常的节点使用与连接排查。