速读#
网上讨论代理方案时，经常把这些名字并排比较：V2Ray、Xray、VMess、VLESS、Trojan、XTLS、REALITY。问题是它们并不属于同一层。
- Xray、V2Ray 是实现与工具。
- VMess、VLESS、Trojan 是代理协议。
- 原始 TCP、WebSocket、gRPC 等是传输方式。
- TLS 是标准安全协议，REALITY 是 Xray 中的安全与握手配置。
- Vision 是流控方式，不是另一个独立协议。
一句“我用 REALITY”其实没有说完整。只有把整条组合写出来，端口、证书、CDN 和客户端兼容性才有办法讨论。
为什么这些名字总被混在一起#
这套生态不是一次设计完再发布的。项目分支、协议演进和社区习惯叠在一起，新名字不断出现，旧教程又长期留在搜索结果里。于是同一个词有时指软件，有时指配置方案，有时只是某个流行组合的简称。
早期文章常按时间线写成“VMess 之后有 Trojan，VLESS 又取代 VMess，后来 XTLS 和 REALITY 更先进”。这种叙述适合了解历史，却容易让人误以为后一个名字和前一个在同一维度竞争。
更稳定的理解方式不是背版本史，而是把一次连接拆成几个配置维度。这里的“层”用于选型和排障，不是严格的 OSI 分层，也不表示后文的箭头就是数据包真实封装顺序。
第一层：谁在运行配置#
Xray Core、V2Ray Core 属于实现层。它们负责读取配置、监听端口、建立出站连接，并实现一种或多种协议与传输。
这和 Nginx 支持 HTTP、TLS、反向代理类似：Nginx 是软件，HTTP 是协议。不能问“Xray 和 VLESS 哪个更快”，因为一个是程序，一个是程序支持的协议。
项目历史和组织关系会变化，但这个判断不变：先确认客户端与服务端运行的核心及版本，再讨论它们共同支持哪些能力。 同名配置项在旧版本里不存在，照抄新教程自然会失败。
第二层：客户端和服务端怎样表明身份#
VMess、VLESS、Trojan 更接近协议层，但设计取向不同。
| 名称 | 可以怎样理解 | 选型时真正要看什么 |
|---|---|---|
| VMess | Project V 生态较早的协议 | 现有客户端兼容、旧配置迁移 |
| VLESS | 负责认证与转发，本身不额外提供完整传输加密 | 必须和 TLS、REALITY 等安全配置一起看 |
| Trojan | 通常与 TLS 一起部署的代理协议 | 证书、域名和 TLS 部署边界 |
这里最容易产生一句误导：“VLESS 不加密，所以不安全。”VLESS 自己不重复造一层加密，不等于完整连接没有安全层；实际配置通常把加密与握手交给 TLS 或 REALITY。评价安全性必须看整套组合，不能只截取协议名称。
同样，“Trojan 看起来就是 HTTPS”也只是简化描述。流量外观、服务行为和是否能被区分，不由协议名字单独保证，错误配置更不会因为选了某个名字就自动消失。
第三层：数据从哪种通道通过#
协议之下还要有传输。常见的 TCP、WebSocket、gRPC 不只是配置表里不同的 network 值，它们决定了中间设施能不能理解和转发这条连接。
| 传输 | 特点 | 常见边界 |
|---|---|---|
| 原始 TCP | 路径直接，额外封装少 | 需要端到端 TCP 可达；当前配置文档常写作 raw |
| WebSocket | 能经过理解 HTTP Upgrade 的反代 | 多一层 HTTP 封装与反代配置 |
| gRPC | 基于 HTTP/2，适合对应代理链 | 上游必须正确支持 HTTP/2 与 gRPC |
这就是为什么“挂到 Cloudflare 域名下”不能回答能否使用。Cloudflare 的普通 Web 代理理解 HTTP/HTTPS，不会自动转发任意原始 TCP；使用 WebSocket 和直接 TCP，入口边界完全不同。
第四层：TLS、REALITY 和证书#
TLS 是标准安全协议，公开部署通常使用域名与受信证书。REALITY 是 Xray 中的一种安全与握手配置，它不是 VLESS 的新名字，也不是通用 TLS 证书服务；它具体支持哪些协议与传输，应以正在运行的 Xray 版本和当前文档为准。
常见组合可以按配置维度写成：
核心：Xray Core协议：VLESS传输：raw（原始 TCP）安全：REALITY流控：xtls-rprx-vision入口：监听地址 + TCP 端口每一行回答一个独立问题：谁执行、用什么协议、走什么传输、如何完成握手、怎样处理流量、从哪个端口进入。它们不是从上到下依次套娃的六个协议，而是共同决定同一条入站连接的配置项。
REALITY 常与 VLESS 一起出现，只说明这套组合常见，不能据此推断其他组合在当前版本一定支持或一定不支持。讨论端口时也一样：443 属于入口选择，不是 REALITY 的协议要求。端口是否可达、是否被 Nginx 占用，仍要单独检查。
第五层：XTLS 和 Vision 在哪里#
XTLS 这个名字在不同阶段指过一组围绕 TLS 流量处理与性能优化的设计。今天配置里更常直接遇到的是 xtls-rprx-vision 这个 flow 值；在 VLESS 入站中，它属于客户端条目的配置，而不是另一个独立监听器。
把它理解为流控层更合适：它不能替代 VLESS 的认证，也不能替代 REALITY 的握手，更不是一个单独监听端口的服务。客户端和服务端必须同时支持并保持参数一致。
旧教程里一些 XTLS 结论可能对应已经变化的实现。看到发布日期较早的文章，先核对 Xray 传输配置、VLESS 入站配置 和实际核心版本，不要只把配置字段复制进新版本。尤其是旧教程中的 network: "tcp" 与当前文档中的 raw 命名，应先确认版本兼容再修改。
一份配置应该怎样说清楚#
以后记录方案时，我不会再只写“VLESS 节点”或“REALITY 节点”，而是至少写出：
核心：Xray Core <version>协议：VLESS传输：TCP安全：REALITY流控：Vision入口：公网 TCP <port>前置：无 CDN / 无 HTTP 反代如果是 WebSocket + TLS + CDN，也应完整写出来。这样排障时才能逐层问：核心是否兼容、认证是否一致、传输是否到达、握手是否通过、入口是否正确转发。
不按“谁更新”选，按约束选#
我会按下面的顺序做决定：
- 所有设备是否有稳定、持续维护的客户端。
- 网络入口允许原始 TCP，还是只能经过 HTTP 代理。
- 443 是否已被网站占用，是否真的值得增加四层分流。
- 是否已有域名和证书维护链路。
- 出问题时能否从监听、传输、握手和认证逐层观察。
对已经稳定工作的旧方案，不必因为新名字出现就立刻迁移。安全更新停止、客户端兼容变差或现有入口不再适配时，再做有回滚路径的变更。
真正该淘汰的不是某个协议名，而是“能连上就不再理解”的配置。把代理栈按层写清楚之后，很多争论会自动消失：它们原本就在回答不同问题。