速读#
网上讨论代理方案时，经常把这些名字并排比较：V2Ray、Xray、VMess、VLESS、Trojan、XTLS、REALITY。问题是它们并不属于同一层。
- Xray、V2Ray 是实现与工具。
- VMess、VLESS、Trojan 是代理协议。
- TCP、WebSocket、gRPC 等是传输方式。
- TLS、REALITY 处理握手、加密或外观。
- Vision 是流控方式，不是另一个独立协议。
一句“我用 REALITY”其实没有说完整。只有把整条组合写出来，端口、证书、CDN 和客户端兼容性才有办法讨论。
为什么这些名字总被混在一起#
这套生态不是一次设计完再发布的。项目分支、协议演进和社区习惯叠在一起，新名字不断出现，旧教程又长期留在搜索结果里。于是同一个词有时指软件，有时指配置方案，有时只是某个流行组合的简称。
早期文章常按时间线写成“VMess 之后有 Trojan，VLESS 又取代 VMess，后来 XTLS 和 REALITY 更先进”。这种叙述适合了解历史，却容易让人误以为后一个名字和前一个在同一维度竞争。
更稳定的理解方式不是背版本史，而是把一次连接拆成几层。
第一层：谁在运行配置#
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 可达 |
| 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 Core -> VLESS -> TCP -> REALITY -> Vision flow -> 服务器端口每一行回答一个独立问题：谁执行、用什么协议、走什么传输、如何完成握手、怎样处理流量、从哪个端口进入。
REALITY 常与 VLESS 一起出现，只说明这套组合流行，不代表两者绑定。讨论端口时也一样：443 属于入口选择，不是 REALITY 的协议要求。端口是否可达、是否被 Nginx 占用，仍要单独检查。
第五层：XTLS 和 Vision 在哪里#
XTLS 这个名字在不同阶段指过一组围绕 TLS 流量处理与性能优化的设计。今天配置里更常直接遇到的是 xtls-rprx-vision 这类 flow。
把它理解为流控层更合适：它不能替代 VLESS 的认证，也不能替代 REALITY 的握手，更不是一个单独监听端口的服务。客户端和服务端必须同时支持并保持参数一致。
旧教程里一些 XTLS 结论可能对应已经变化的实现。看到发布日期较早的文章，先核对当前核心文档和版本，不要只把配置字段复制进新版本。
一份配置应该怎样说清楚#
以后记录方案时，我不会再只写“VLESS 节点”或“REALITY 节点”，而是至少写出：
核心：Xray Core <version>协议：VLESS传输：TCP安全：REALITY流控：Vision入口：公网 TCP <port>前置：无 CDN / 无 HTTP 反代如果是 WebSocket + TLS + CDN，也应完整写出来。这样排障时才能逐层问：核心是否兼容、认证是否一致、传输是否到达、握手是否通过、入口是否正确转发。
不按“谁更新”选，按约束选#
我会按下面的顺序做决定：
- 所有设备是否有稳定、持续维护的客户端。
- 网络入口允许原始 TCP，还是只能经过 HTTP 代理。
- 443 是否已被网站占用，是否真的值得增加四层分流。
- 是否已有域名和证书维护链路。
- 出问题时能否从监听、传输、握手和认证逐层观察。
对已经稳定工作的旧方案，不必因为新名字出现就立刻迁移。安全更新停止、客户端兼容变差或现有入口不再适配时，再做有回滚路径的变更。
真正该淘汰的不是某个协议名，而是“能连上就不再理解”的配置。把代理栈按层写清楚之后，很多争论会自动消失：它们原本就在回答不同问题。