VLESS

VLESS 是 V2Ray/Xray 团队推出的一种轻量级、无状态的代理协议,定位为 VMess 的简化继任者。它最大的特点是协议层本身不做加密,而是把机密性与完整性完全交给外层的 TLS 来负责;VLESS 自己只用 UUID 做最小化的身份标识与目标寻址。这一设计去掉了 VMess 中自带的加密、alterId 与时间戳认证带来的额外开销与特征,使流量在叠加真实 TLS 后更接近普通 HTTPS,既轻量又便于伪装。正因为定位为现代 TLS 化代理的承载层,VLESS 常与 XTLS、Vision、Reality、gRPC、WebSocket 等技术搭配,成为当下自建抗封锁部署最热门的协议之一。

背景与由来

VMess 虽功能完整,但其自带加密层、alterId、时间戳认证在实践中既增加复杂度,又可能引入可被分析的特征,还要求两端时钟同步。Xray-core 团队据此提出 VLESS,核心理念是:既然外层已有 TLS 提供机密性与完整性,代理协议内部就无需重复加密,只保留必要的鉴权与寻址即可。这种做减法的设计降低了 CPU 开销(避免双重加密)、消除了对时间同步的依赖,也减少了协议指纹,顺应了整个代理领域从自造混淆/加密转向真 TLS 化的演进趋势。VLESS 也为 XTLS 系列性能优化提供了协议层的支点。

设计目标

• 无状态与极简:协议头精简,不维护复杂会话状态与认证窗口,处理开销小、易于实现。
• 加密外置:机密性由 TLS 承担,VLESS 不重复加密,避免双重加密带来的性能损耗与额外特征。
• 易于伪装:配合 TLS/Reality 后,流量外观尽量贴近正常 HTTPS,降低被识别概率。
• 为高性能优化预留空间:通过 flow 字段支持 XTLS 的零拷贝/流控优化,处理 TLS-in-TLS 场景。

工作原理

VLESS 的请求结构相当精简。在(通常已经建立的)TLS 通道内,客户端发送一个头部,包含协议版本号、16 字节 UUID、附加指令长度与内容、命令(TCP/UDP/MUX)、目标地址类型、目标地址与端口,随后紧跟应用数据。服务器用 UUID 在用户表中匹配,成功后直接代为连接目标并双向转发;UUID 不匹配则按配置处理(如断开或回落)。由于自身不加密,VLESS 头部在 TLS 内部是明文结构,但因为整条链路被 TLS 包裹,外部观察者只能看到标准的 TLS 记录。VLESS 还引入了关键的 flow 字段以支持 XTLS 系列优化,其中 xtls-rprx-vision 是当前主流:它在转发 TLS-in-TLS(代理内层又是 TLS,如访问 HTTPS 网站)时,通过识别内层 TLS 握手、对已加密的数据避免再次加密、并对长度与时序做修整,从而降低 CPU 开销并修整可被指纹化的长度特征,让流量更难与正常 HTTPS 区分。

传输特性

VLESS 与 V2Ray/Xray 的传输层解耦,常见承载组合包括:

• TCP + TLS:最经典,流量呈现为标准 HTTPS,需真实域名与证书。
• XTLS / Vision(xtls-rprx-vision):针对 TLS-in-TLS 场景的优化流控,降低 CPU 占用、修整长度特征,提升抗指纹能力。
• Reality:无需自有域名与证书,借用真实大站证书完成 TLS 握手,极大提升抗主动探测能力(详见 Reality 词条),是当前 VLESS 的热门搭档。
• gRPC / WebSocket / HTTP2:便于过 CDN、与正常 Web 流量混同,适合需要中转或隐藏 IP 的场景。

VLESS 同样可使用 mux 多路复用,但在 XTLS/Reality 等追求流量真实性的场景下,出于不破坏与正常 HTTPS 一致外观的考量,常不启用复用。它支持 TCP 与经封装的 UDP 转发。值得一提的是,VLESS 头部本身只携带极少的元信息,因此在 TLS 之内几乎不增加可被统计的额外字节,这也是它相比 VMess 更难被流量分析的重要原因之一;而 flow 与传输方式的不同组合,则让同一协议能适配从过 CDN 隐藏 IP 到直连追求极致性能的多种部署目标。

在工程实践中,VLESS 的一个常见误区是把它当作可独立提供安全性的协议来理解。实际上,若关闭 TLS 直接裸跑 VLESS(none 加密、none 安全层),其请求头中的 UUID 与目标地址在链路上虽不直接明文可读(取决于承载),但缺乏机密性保障,且极易被特征化识别,因此官方与社区都明确反对这种用法。正确的心智模型是:VLESS 负责寻址与鉴权,TLS/Reality 负责加密与伪装,二者缺一不可,这也正是其无状态轻量设计能成立的前提。

演进关系与对比

• 相对 VMess:VLESS 去掉自带加密与时间戳认证,更轻、特征更少、不依赖时间同步,在有 TLS 的部署里被广泛视为更优选择。
• 相对 Trojan:两者都把加密交给 TLS、追求 HTTPS 化外观,理念高度相近;VLESS 更偏向 Xray 生态并可深度结合 XTLS 与 Reality,Trojan 则以回落机制与配置直观见长。
• 必须强调:VLESS 不能脱离 TLS 裸用,否则头部明文且无机密性保护,既无隐私也极易被识别甚至被探测利用,因此实践中几乎总与 TLS 或 Reality 绑定。
• VLESS+Vision+Reality 已成为近年自建抗封锁节点的代表性组合,体现了协议层做减法、安全交给成熟 TLS 的设计哲学。

实现与客户端生态

VLESS 主要由 Xray-core 实现并发扬光大,V2Ray-core 与 sing-box 等也支持。客户端覆盖 v2rayN、v2rayNG、Clash.Meta(Mihomo)、sing-box、NekoBox、Hiddify 等,分享链接以 vless:// 形式携带 UUID、传输方式、flow、TLS/Reality 参数(如 sni、fingerprint、publicKey、shortId)。配合 Reality 的 VLESS 因免证书、强抗探测,已成为高级用户与机场的常见选择。各客户端对 flow、fingerprint(伪装的浏览器 TLS 指纹,如 chrome、firefox、safari)与 Reality 参数的支持已较为完善,导入订阅后通常可直接使用。

从生态演进看,VLESS 的崛起也带动了 Xray-core 与 V2Ray-core 的分化:Xray 团队围绕 VLESS、XTLS、Vision、Reality 持续迭代出一整套现代抗封锁组合,使 Xray 成为该方向事实上的领跑实现;而 sing-box 等新一代多协议内核则把 VLESS 与 Hysteria2、TUIC、Shadowsocks 等并列支持,让用户可在同一客户端中灵活切换或并用多种协议,VLESS 通常作为其中的主力直连协议存在。

适用与局限

VLESS 适合追求高性能、低特征、强伪装的现代部署,尤其是 VLESS+XTLS-Vision+Reality 这类组合,在抗主动探测与 CPU 效率上表现突出。其局限是:强依赖正确配置的 TLS/Reality,一旦证书、SNI、回落或 Reality 的目标站等配置不当,就可能暴露甚至比简单协议更脆弱;其抗封锁效果很大程度取决于外层伪装质量,而非协议本身。整体上,VLESS 代表了代理协议极简化、把安全责任交给成熟 TLS 的主流方向。它的成功也说明,在抗封锁这件事上,协议自身的复杂度往往不是优势而是负担——越少的独有特征,越能融入正常加密流量的汪洋之中,而把机密性、伪装与指纹问题交给历经全球检验的 TLS 生态去解决,通常比自造一套更可靠。