REALITY 主要处理代理连接的握手与身份验证，XTLS Vision 主要处理隧道内数据的识别与传输优化。两者可以组合，但不是同一个功能。本文从 VLESS、TLS 与传输层的关系讲起，说明免自签证书的边界、重复加密的优化条件，以及 v2rayN、v2rayNG 中需要核对的字段，适合已经导入订阅、准备排查连接或比较配置的读者。
协议层次：VLESS、REALITY 与 Vision
先给结论：常见的“VLESS + TCP + REALITY + Vision”是多个层次的组合，不是四个可互换的协议名称。VLESS 提供代理请求格式与用户认证信息；TCP 承载连接；REALITY 建立具有认证机制的安全连接；Vision 则是 Xray 中与特定传输组合配合的流控模式。
VLESS 自身不承担载荷加密。因此，看到客户端里的 VLESS 加密字段为 none，不能直接推断网络上在传输明文。还要看外层是否启用了 REALITY 或 TLS，以及应用本身是否使用 HTTPS。VMess 的协议机制不同，也不能把 VLESS 的字段直接移到 VMess 配置里。
| 名称或字段 | 承担的工作 | 检查重点 |
|---|---|---|
| VLESS | 表达代理目标与用户身份。 | 用户 ID 与服务端一致。 |
| TCP | 提供可靠、有序的字节流。 | 地址、端口与传输方式一致。 |
| REALITY | 处理安全握手与对端认证。 | 服务端公钥、serverName、shortId。 |
| xtls-rprx-vision | 识别内层流量并优化符合条件的数据转发。 | 两端流控与传输组合相容。 |
REALITY 握手与免自签证书
“免自签证书”指代理服务端通常不需要像传统 TLS 部署那样，为自己的代理域名申请并续期证书，也不需要让用户手动信任一张自签证书。这不等于省略身份验证，更不等于可以关闭证书相关检查。REALITY 使用自身的认证设计，客户端必须持有正确的服务端公钥等参数。
服务端会配置一个真实 TLS 站点作为握手目标。REALITY 借助与目标站点相关的握手行为，使对外表现尽量贴近正常 TLS 服务；带有正确认证信息的客户端会进入代理处理路径。不满足认证条件的连接可按实现与配置被转发至目标站点，而不是获得代理权限。“借用真实站点握手”只是概括，不是复制该站点的私钥。
这里有两个容易混淆的地址：客户端连接的是代理服务器地址；serverName 则是握手使用的名称，应符合服务端允许的设置。把它随意改成一个熟悉的网站域名，并不能让连接自动成功。真实目标站点也不是代理服务器的替代品：认证后的代理流量通常仍由代理服务器访问目标业务，不是让该站点承担通用流量中转。
Vision 流控与重复加密
打开 HTTPS 网站时，浏览器已经与网站建立了一层 TLS 连接。如果这段加密流量再进入另一条 TLS 类代理隧道，就会出现“加密数据再被外层加密”的结构。额外的记录封装、缓冲与加解密处理可能消耗 CPU，也可能形成可被观察的嵌套流量特征。
Vision 会识别隧道内的 TLS 握手和数据阶段，并在前期使用填充等处理；对符合条件的内层 TLS 1.3 流量，可以切换到直接复制等优化路径，减少外层重复处理。它不是把所有连接都改成明文，也不是解开浏览器与网站之间的 HTTPS。应用到网站的端到端 TLS 仍然存在。
- 符合条件的 HTTPS 流量：可能进入减少重复加密的路径，实际效果还受内核版本、平台和连接形态影响。
- 普通明文业务：不能套用“本来已有 HTTPS 保护”的前提，仍需由外层安全机制保护。
- UDP 与其他流量：不能直接套用 TCP 内层 TLS 的优化结论；UDP 承载与转发能力需要另行检查。
- WebSocket 等组合：不能仅在现有节点上增加 Vision 字段就期待生效，应核对该内核支持的完整组合。
因此，“Vision 减少重复加密”比“Vision 不加密”准确。并非每条连接、每一个字节都会进入同一条优化路径。把流控名称填对，只是启用相应机制的必要条件，不是带宽提升的保证。
关键数字与客户端字段
下面的数字用于理解协议和检查配置，不是测速结果。443 是常见部署端口，但不是 REALITY 的强制端口；服务端实际监听其他端口时，客户端也必须跟随修改。shortId 则按十六进制填写，长度必须符合内核要求，并与服务端允许的值相符。
在使用经典字段的 Xray REALITY 配置中，shortId 最多为 8 字节，也就是 16 个十六进制字符，字符数应为偶数。是否允许空值取决于服务端设置，不能因为界面允许留空就删除订阅给出的值。客户端界面可能将公钥字段显示为 Public key 或其他随内核演进调整的名称，应结合订阅格式与当前内核文档核对。
VLESS + REALITY + Vision
- 传输
- TCP，部分界面称 RAW
- 安全层
- REALITY
- Flow
- xtls-rprx-vision
- 认证参数
- 用户 ID、公钥、shortId
- 握手名称
- 与服务端允许值一致
这是一组常见组合说明，不是可直接连接的节点配置。
VLESS + TLS + Vision
- 传输
- TCP，部分界面称 RAW
- 安全层
- TLS
- Flow
- xtls-rprx-vision
- 证书
- 需要有效证书与信任链
- 握手名称
- 与证书域名匹配
Vision 不依赖 REALITY 才能存在，传统 TLS 组合也需要两端支持。
在 v2rayN 中应先确认当前节点使用支持该组合的 Xray 内核，再编辑对应的 VLESS 服务器参数；v2rayNG 使用 Xray 内核，同样需要完整的节点字段。v2flyNG 使用 V2Fly 内核，不能因为界面也能导入 VLESS，就推断它支持 Xray 的 REALITY 与 Vision。客户端版本、内核能力与订阅解析能力是三项独立检查。
速度、延迟与稳定性边界
REALITY 的主要意义不是缩短地理距离，Vision 也不会替服务器增加带宽。若瓶颈来自高峰拥塞、跨地区链路或服务端出口限制，减少一部分加密开销未必带来明显变化。CPU 已接近饱和、且业务以符合条件的 HTTPS 长连接为主时，Vision 的资源收益才更容易显现。
- 固定对照条件：使用同一设备、同一网络、同一测试文件和相近时段；只有服务端确实提供两组可比配置时，才进行协议对比。
- 区分测试指标：连接延迟测量、网页首字节时间和持续下载吞吐不是一回事。记录测试方式，不把客户端的一次延迟读数当成总性能。
- 记录本地资源：观察测试期间的 CPU 占用与客户端日志，避免把设备发热降频或后台下载造成的变化归因于协议。
- 重复测试：每种配置至少重复 3 次，同时记录失败与超时；只挑最快的一次容易误判。
选择依据：先确认瓶颈，再比较流控
如果日志显示连接已建立、CPU 也有余量，应先比较链路丢包、服务端负载与出口带宽，而不是反复修改 Vision 字段。只有在可比条件下观察到稳定差异，才有理由把变化归因于配置组合。
稳定性还取决于服务端到握手目标的可达性、目标站点的 TLS 行为、系统时间以及两端实现的兼容性。REALITY 可以改变连接呈现方式，但不能保证任何网络环境下持续可用。选择目标站点属于服务端运维工作，订阅用户不宜仅修改本地 serverName 来尝试“修复线路”。
连接排查与常见问题
排查顺序应从最容易核实的字段开始：地址与端口、用户 ID、传输方式、安全层、流控、公钥、shortId、握手名称，最后再看路由与 DNS。每次只改一项并重试，保留原始订阅配置作为对照。分享日志前先删去订阅链接、用户 ID 和服务器敏感信息。
导入成功，为什么还是连接超时？
导入成功只表示客户端能解析文本。先核对服务器地址与实际监听端口，例如节点写 443 就不要自行改成 8443；再查看内核日志。连接超时通常应先查网络可达性、防火墙和服务端监听，不能仅凭超时认定是公钥错误。
提示握手失败，应该打开跳过验证吗？
不要把跳过验证当作通用修复。先同步设备时间，再逐项核对公钥、shortId 与 serverName；使用订阅时，更新后重新选择原节点测试。REALITY 的认证参数有误时，需要取得正确参数，关闭检查并不能恢复正确的身份关系。
节点能连接，为什么部分应用打不开？
先确认应用流量是否真的进入客户端。桌面应用可能不遵循系统代理，需检查应用自身的代理设置，或按教程配置 Tun 模式。再检查路由规则是否把目标分到直连，以及 DNS 是否能正常解析；不要先改 REALITY 公钥。
启用 Vision 后没有变快，需要换节点吗？
先用相同 HTTPS 文件重复下载 3 次，并观察 CPU 与错误日志。如果吞吐相近且连接稳定，可以继续使用。若持续受出口带宽限制，修改流控没有帮助；应在同一时段比较其他可用线路，而不是堆叠更多传输选项。
现有 VMess 节点能直接改成 REALITY 吗？
不能只在客户端切换协议名称。服务端必须提供对应的 VLESS、REALITY 与流控配置，并给出配套认证参数。先取得新的完整节点或订阅，再导入 v2rayN 或 v2rayNG；保留旧节点，方便检查与回退。
配置选择与操作顺序
已经有可用订阅时，优先保留服务端给出的组合。判断节点是否适合，不应只看名称里有没有 REALITY 或 Vision，而要看客户端能否完整支持、连接是否稳定、常用应用是否正常，以及实际线路是否满足用途。
- 先核对内核：REALITY 与 Vision 应按 Xray 的支持情况选择，不能把 Project V / V2Fly / Xray 家族名称当成完全兼容的承诺。
- 再导入完整参数：使用可信订阅，避免混用不同节点的公钥、用户 ID 与握手名称。
- 最后验证使用路径：先测试单个 HTTPS 网站，再检查系统代理、Tun、DNS 和路由分流。
需要了解规则顺序时，可查看进阶配置；订阅导入与基础连接步骤见入门指南的订阅说明。先建立能重复验证的基线，再逐项调整，通常比一次更改多个协议字段更容易定位问题。