VLESS 负责代理协议，REALITY 负责连接的安全握手，XTLS Vision 负责特定流量的转发优化。本文适合已经导入节点、但不清楚 Flow、公钥与 SNI 各管什么的用户。读完可以区分性能收益与线路瓶颈，并按服务端参数核对 v2rayN 配置。
VLESS、REALITY、Vision 分别位于哪一层
节点名称中的“VLESS + TCP + REALITY + Vision”不是四种互相替代的协议。它描述同一条代理连接的不同设置。VLESS 携带用户身份和目标地址；TCP 承载字节流；REALITY 提供安全握手与认证机制；Vision 则是 VLESS 的一种流控方式，在符合条件时优化后续数据路径。
| 名称 | 主要职责 | 需要核对的字段 |
|---|---|---|
| VLESS | 代理请求、用户身份与目标信息 | 地址、端口、UUID |
| TCP / RAW | 承载连接的有序字节流 | 传输类型；界面命名随版本变化 |
| REALITY | 安全握手与服务端认证 | SNI、公钥或对应认证字段、Short ID |
| XTLS Vision | 识别流量并选择转发路径 | xtls-rprx-vision |
VLESS 本身不提供传统意义上的载荷加密，常见配置中的 encryption=none 并不代表整条连接以明文传送。使用 REALITY 时，安全保护来自外层机制。不要为了“增加安全性”把 VLESS 的加密字段随意改成其他协议的选项。
本文讨论 Xray 的 VLESS + REALITY + Vision 组合。v2rayN 是管理节点与调用内核的客户端，不是该组合本身；判断能否连接，要看实际启动的内核和生成的配置，不能只看软件名称。
HTTPS 进入代理后，重复加密发生在哪里
浏览器访问 HTTPS 网站时，会与目标网站建立 TLS 会话。代理通常只负责搬运这些已经加密的数据，并不解密网页内容。如果代理链路又使用一层 TLS，客户端就可能需要把内层 TLS 数据再次包装、加密后发往代理服务器，服务端再解开外层。
这里存在两段不同的安全关系：内层保护浏览器与网站之间的内容，外层保护客户端与代理服务端之间的传输。两层有各自用途，但对已经加密的大流量再做一次完整加密，会增加 CPU 运算、缓冲区处理与数据复制等成本。在高吞吐、处理器较弱的环境中，这些成本更容易成为瓶颈。
也不是所有请求都属于这一模型。普通 HTTP 没有网站 TLS 层，UDP 流量也不是一条可直接套用相同处理路径的 HTTPS 字节流。因此，“减少双重加密”不能被理解为所有应用都会获得固定比例的加速。
XTLS Vision 如何调整数据转发路径
Vision 不会在连接开始时直接关闭保护。它先处理协议头与初始数据，并识别内层 TLS 的状态。对符合条件的 TLS 1.3 流量，在适当阶段切换到优化的数据路径，避免继续对已经加密的应用数据做不必要的外层重复加密。
- 先建立连接。客户端与服务端完成外层安全握手，并传递 VLESS 身份和目标地址信息。
- 再识别流量。Vision 检查内层 TLS 握手与记录特征；初始阶段还会使用填充机制，调整早期数据包特征。
- 满足条件才切换。对于适合优化的 TLS 1.3 流量，进入直接转发路径，继续由内层 TLS 保护网站数据。
- 其他流量保留相应处理。未满足条件时，不应假定已经消除外层加密；实际路径由内核判断。
“直接转发”也不等于固定启用某一种操作系统级零拷贝。具体能否进一步减少复制，取决于系统、连接形态与内核实现。配置里写了 xtls-rprx-vision，只能说明启用了该流控，不能据此承诺每条连接都走同一条高速路径。
判断：先确认 CPU 是否构成瓶颈
同一条线路上，若下载已占满带宽且 CPU 仍有余量，启用 Vision 后速度可能基本不变；若客户端或服务端单核持续繁忙，再比较相同文件、相同时段下的吞吐和 CPU 占用。
REALITY 如何省去自备证书
常规 TLS 服务端通常需要为自己的域名部署证书和私钥。REALITY 使用不同的握手与认证设计，结合目标站点的 TLS 握手特征，使代理服务端不必按常规方式为代理域名申请和续期公开证书。它不是让用户把任意网站证书复制到服务器上。
客户端仍要验证连接是否可信。常见部署使用服务端生成的 X25519 密钥对：私钥只保留在服务端，公钥分发给客户端；客户端还需要正确的 SNI、Short ID 等参数。Short ID 参与连接识别，但不能替代密钥认证，也不应把它理解成唯一的登录密码。
- SNI：必须匹配服务端允许的服务器名称。连接地址可以是 IP，SNI 则通常是域名；二者不是同一个字段。
- 公钥：来自该节点服务端配置。不能使用目标网站的证书公钥，也不能从另一个节点随意复制。
- Short ID：应与服务端允许的值一致。它使用十六进制表示，长度也受配置约束；优先保留订阅原值。
- 指纹：客户端常见选项为
chrome，用于构造相应的握手特征，不代表必须使用该浏览器。 - 时间：保持设备系统时间正确。服务端若设置时间差限制，明显的时钟偏差会导致认证失败。
服务端还会设置握手目标，配置名称可能显示为 target 或旧版的 dest。目标站点需要具备合适的 TLS 能力且从服务端可达，选择不当会影响握手。未通过认证的连接可被转向目标站点，但这种处理不代表任何网络环境下都无法识别代理。
v2rayN 配置：按字段核对，不按节点名称猜
先导入服务方提供的完整订阅或分享链接，再打开节点编辑窗口。以下两张卡是同一连接的字段核对示意，不是可以直接使用的节点参数。端口 443 只是常见部署示例，实际值必须以服务端为准。
VLESS 与传输字段
- 协议
- VLESS
- 服务端端口
- 443（示例）
- 传输
- TCP / RAW
- 加密
- none
- Flow
- xtls-rprx-vision
地址与 UUID 使用节点原值，Flow 必须得到服务端支持。
REALITY 认证字段
- 安全类型
- reality
- SNI
- 服务端允许的域名
- 公钥
- 该服务端分发的公钥
- Short ID
- 与服务端匹配的十六进制值
- 指纹
- chrome（常见选项）
界面字段名可能随内核和客户端版本变化，导入后仍需核对。
在 v2rayN 中进入「设置」→「参数设置」，核对本地监听端口；再检查当前节点实际使用的内核。菜单细项随版本变化，但本地端口与远端端口始终是两件事。浏览器连接本地代理入口，内核才会连接节点的远端端口。
安卓使用 v2rayNG 时，同样要检查 VLESS、REALITY 与 Flow 字段及其内核支持。v2flyNG 使用 v2fly 内核，不能把本文的 Xray 专属组合当成通用配置原样套入。节点能够被列表识别，不等于当前内核一定能运行其中所有功能。
如何验证“更快”，而不是只看延迟数字
比较协议时，应尽可能保持服务端、出口和测试目标一致。拿两台不同地区的服务器比较，会把线路差异误算成协议收益。普通 TCP 连通测试只说明某个端口可以建立连接，既不能证明 REALITY 认证成功，也不能证明 Vision 已进入优化路径。
- 固定条件：记录客户端与内核版本、节点地址、传输方式、Flow、系统代理状态，关闭其他下载任务。
- 确认实际经过代理：查看日志中的目标连接和路由结果，避免测速域名命中直连规则。
- 分开记录指标：记录网页首包耗时、持续下载速度、客户端与服务端 CPU 占用，不把单次延迟作为总评分。
- 重复采样：每组运行 3 次，每次持续 60 秒，采用中位数比较。这是测试方法建议，不是本文的实测结果。
- 解释异常：速度下降时同时检查丢包、服务端负载和出口限速；CPU 降低而速度不变，也可能说明带宽已成为上限。
选择：保留稳定可用的组合，再验证优化收益
先让服务端与客户端参数完全匹配，再测试 Vision 的效果。不要同时修改 Flow、传输类型和路由模式；每轮只改一个变量，才能定位性能变化来自哪里。
REALITY 与 Vision 连接失败的常见问题
端口测试能通，为什么网页仍然打不开？
先看内核日志是否完成握手，再逐项核对 UUID、SNI、公钥和 Short ID。端口可达只是 TCP 层结果。若握手成功但网页失败，继续检查 DNS 和路由；在 v2rayN 托盘菜单确认系统代理入口，并核对浏览器是否另设了代理。
把 Flow 改成 Vision 就能加速吗？
不能只修改客户端。打开节点编辑窗口，将 Flow 与服务端配置对照；服务端未使用对应流控时，单方面填入 xtls-rprx-vision 可能直接连接失败。订阅节点优先保留服务方下发的值。
REALITY 的 SNI 可以换成常用网站吗？
先检查服务端允许的名称，不能随意替换。连接地址、SNI 和服务端握手目标具有不同作用。恢复订阅原值后重启连接；仍失败时，请服务端维护者检查目标可达性和系统时间。
更新客户端后提示参数不认识，应该删哪个字段？
先记录客户端和实际内核版本，查看日志中指出的字段，再重新导入完整订阅。新旧内核可能使用不同字段名称，不要直接删除认证字段或关闭验证。桌面端先确认该节点调用的是支持此组合的 Xray 内核。
排查顺序应保持稳定：本地入口、远端端口、认证参数、内核兼容、DNS 与路由，最后再做性能比较。REALITY 的部署方式和 Vision 的转发优化可以减少特定环节的成本，但可用性仍由完整链路决定。