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

VLESS 协议是什么：无状态设计、UUID 认证与传输层组合

VLESS 一句话定义

VLESS 是一种「只负责认证和告诉节点去哪」的代理协议，它不负责加密，也不维护会话状态。它最初出现在 V2Ray 社区，后来在 Xray 项目中得到主要发展，如今被 sing-box、mihomo 等多个内核实现。

理解 VLESS 的关键，是把它看成整个协议栈里的一层，而不是一个完整方案。人们常说的「VLESS 节点」，实际上一定是「VLESS + 某种传输 + 某种安全层」的组合：

┌───────────────────────────────┐
│ 应用数据                       │
├───────────────────────────────┤
│ VLESS 头：版本 | UUID | 指令    │  ← 认证 + 目标地址
│          端口 | 地址类型 | 地址 │
├───────────────────────────────┤
│ 安全层：TLS 或 REALITY         │  ← 加密与完整性
├───────────────────────────────┤
│ 传输：TCP / WebSocket / gRPC   │  ← 承载
└───────────────────────────────┘

请求头里装了什么

VLESS 请求头非常精简，基本只包含版本号、用户 UUID、附加字段、指令类型和目标地址。客户端建立连接后先发送这段头部，紧接着就是应用数据，服务端校验 UUID 通过后直接转发。

与 VMess 相比，VLESS 去掉了基于时间的认证和协议内加密，因此不依赖客户端与服务端的时钟同步，也减少了每个请求的计算开销。这也是为什么 VLESS 常被描述为「无状态」：服务端不需要为每个用户维护时间窗口或会话信息，只需对比 UUID。

为什么不加密反而是合理设计

VLESS 不加密的前提，是它总是运行在一个已经加密的通道里。如果外层已经是 TLS 1.3，再在内部做一遍对称加密，就属于重复劳动，既增加 CPU 开销，也不会带来额外的机密性。

但这个设计也带来一个直接后果：VLESS 绝不能裸跑。如果服务端把 VLESS 直接暴露在没有 TLS 或 REALITY 的 TCP 端口上，UUID 与目标地址都会以明文形式在网络上传输。正规服务商提供的配置都会带安全层，用户在订阅里能看到 security: tls 或 security: reality 之类的字段。如果你看到的配置里安全层为空，应该先向服务商确认。

关于外层安全层的原理，可以阅读 代理协议中的 TLS 与 REALITY 是什么。

常见传输组合与差异

VLESS 可以搭配多种传输方式，不同组合主要影响兼容性与中转能力，而不是绝对速度。下面是几种常见组合的定位：

有些配置还会出现 flow 字段，例如与 XTLS Vision 相关的流控设置。它的作用是在特定条件下减少「TLS 套 TLS」带来的冗余处理与特征。这类参数应完全按照服务商下发的订阅使用，不建议手动修改，否则很可能导致连接失败。

客户端兼容：最容易踩的坑

VLESS 的使用门槛主要在客户端，而不在协议本身。并不是所有标着「Clash」的客户端都支持 VLESS：原版 Clash 内核不支持，基于 mihomo（原 Clash Meta）内核的客户端支持；sing-box 与 Xray 系客户端也支持，但对 REALITY、Vision 等扩展的支持程度与版本有关。

排查顺序建议如下：

导入订阅后 VLESS 节点缺失或报错
├─ 节点列表中完全没有 → 检查客户端内核是否支持 VLESS
├─ 有节点但无法连接
│   ├─ 报 REALITY / flow 参数错误 → 客户端版本过旧，升级后重试
│   └─ 超时 → 转入网络层排查（线路、DNS、本地网络）
└─ 部分节点可用 → 多为节点自身状态，联系服务商

具体客户端的选择与导入步骤，请参考 桌面客户端 与 移动客户端 专题；订阅格式与转换问题见 订阅管理。

资料标注 VLESS 的品牌怎么理解

本站品牌库中，光速云、U1S1、唯兔云、宇宙云、光年梯、一翻云、二猫云、SOGO云、可信云、速界、快狸、全球云的品牌资料标注协议为 VLESS。这只说明品牌资料如此描述，本站没有独立核验节点的实际协议，也没有实测连接速度与稳定性（Not Tested）。

另有微风网络、飞猫云、星岛梦、灵猫网络、极连云五个品牌，资料未给出协议，本站统一显示「待核实」，不做任何推测。如果你的客户端只支持部分协议，这类品牌需要在购买前自行确认协议类型。

即使同为 VLESS，不同品牌在传输组合、安全层、线路与节点负载上都可能不同。协议相同只能说明客户端兼容条件相近，不能说明使用体验相近。

UUID 的保管与轮换

UUID 在 VLESS 中承担的是凭证角色，泄露的后果与密码泄露类似。服务端只认 UUID，不认设备，所以任何拿到你 UUID 和节点地址的人，理论上都能消耗你的套餐流量，甚至触发服务商的设备数或滥用限制。

在机场场景下，UUID 通常不需要用户自己生成，而是由服务商在订阅中下发。常见的泄露途径包括：把订阅链接发到群聊或截图分享、使用来路不明的在线订阅转换工具、在不可信设备上登录账号。一旦怀疑泄露，最直接的处理方式是在服务商面板中重置订阅，这通常会同时更换 UUID，旧配置随即失效。更多订阅安全实践可参考 安全与隐私 专题。

还有一点容易被忽略：UUID 本身不提供任何加密能力，它只是一个标识符。网络上传输时，UUID 是否被保护，完全取决于外层安全层是否存在且配置正确，这再次说明了「VLESS 必须搭配安全层」的必要性。

小结

VLESS 的核心价值在于精简：用 UUID 做认证、把加密交给成熟的安全层、不依赖时间同步。它的风险点也很明确：必须搭配安全层，且需要客户端内核支持。理解这两点，就能读懂大部分 VLESS 节点配置的含义。

想按协议字段筛选品牌，可以前往 机场品牌库 或查看 VLESS 标签；如果想并排比较两个品牌的协议与线路资料，可以使用 对比工具。协议之间的整体差异，可回到 代理协议 专题总览。