REALITY 处理外层连接的认证与握手表现，XTLS Vision 处理符合条件的数据流转发，两者不是同一个协议开关。本文面向已经拿到 VLESS 配置、需要理解 SNI、公钥、shortId 与 flow 的读者，按握手、加密层次和客户端排查顺序说明。读完可以区分配置字段的职责，也能判断“握手失败”和“连接后打不开网页”应从哪里查起。
一、VLESS、REALITY 与 Vision 分别负责什么
常见的“VLESS + REALITY + Vision”是一组分层组合。VLESS 携带用户标识与目标地址等代理请求信息，本身不提供应用数据加密；REALITY 提供这一组合中的安全传输与认证机制；Vision 对符合条件的流量采用更合适的转发方式。把三者都称为“加密协议”，会导致设置项对不上。
连接与认证层
- 代理协议
- VLESS
- 用户标识
- UUID
- 安全传输
- REALITY
- 服务端认证
- 公钥与握手验证
UUID 与 REALITY 公钥承担不同职责，不能互相替代。
本文讨论的传输组合
- 底层传输
- TCP / RAW，名称依版本而异
- 流控值
xtls-rprx-vision- 握手指纹示例
chrome- 常见远端端口
- 443，以实际配置为准
不要给这组组合额外添加 WebSocket 路径或其他传输封装。
v2rayN 是桌面图形客户端，实际能否使用某项功能取决于所选内核；v2rayNG 使用 Xray 内核。v2flyNG 使用 v2fly 内核，不能因为名称相似就假定可以处理相同的 REALITY 与 Vision 配置。导入成功只说明客户端接受了输入，不等于当前运行内核已经具备对应能力。
二、REALITY 的“借用握手”不是取得目标站私钥
普通 TLS 连接中，浏览器通过证书链和域名验证确认网站身份。REALITY 的设计则需要同时面对两类连接：持有正确认证材料的客户端，以及不携带有效认证材料的普通访问或探测。它利用目标站点的握手表现与回落转发机制，使未认证连接能够表现为访问该目标站，而不是直接返回明显的代理服务错误。
上面的流程描述的是认证成功的代理连接。客户端根据预配置的服务端公钥及握手上下文验证 REALITY 的临时证书机制，而不是简单地把任意证书当作可信证书。服务端并没有获得目标站的私钥，也不是给目标站签发了一张公开可信的替代证书。“借用证书特征”适合作为直观描述，但不能理解为复制证书后就能冒充任意网站。
对于未通过 REALITY 认证的连接，服务端可将其转发到配置的目标站点，访问者看到的是目标站真实的 TLS 行为。目标站点因此不是随便填入的装饰字段：服务端到目标站的可达性、TLS 1.3 支持和连接行为都会影响配置质量。新旧 Xray 配置中，服务端目标字段可能显示为 target 或旧名 dest，应按运行版本核对。
三、Vision 减少的是哪一层重复加密
浏览器访问 HTTPS 网站时，浏览器与目标网站之间已经存在一层 TLS。若再把整条连接包进代理的外层 TLS，同一段应用密文就可能再次经历外层记录封装与加密。代理服务器还需要处理外层解密与转发，这会增加计算和数据搬运开销，但增加多少取决于实现、硬件和流量类型。
| 阶段或流量 | Vision 的处理思路 | 不能据此推断的结论 |
|---|---|---|
| 连接初期与代理请求 | 完成外层安全握手、认证和必要的协议处理。 | 不是从第一个字节起就绕开安全通道。 |
| 符合识别条件的内层 TLS 1.3 流量 | 在安全切换条件满足后，可转入直接复制路径，减少继续套用外层 TLS 的开销。 | 不是所有 HTTPS 连接都必然进入该路径。 |
| 普通明文或不符合切换条件的流量 | 仍按相应的受保护转发路径处理。 | 不能宣称所有数据都省掉一层加密。 |
| 底层系统数据转发 | 在内核、操作系统和连接条件允许时，还可能利用更高效的数据搬运方式。 | 开启 Vision 不等于必然实现零拷贝。 |
这里的“直接复制”不等于把网页明文暴露在网络上。进入相应路径的数据本身仍受到浏览器与目标网站之间的 TLS 保护。Vision 根据内层协议状态做识别和切换，并非简单地关闭加密；无法满足条件时也不能照搬这条解释。
判断：先验证流控一致，再比较吞吐
先确认客户端与服务端都使用 xtls-rprx-vision，再用同一条线路、同一个 HTTPS 大文件和相近时间段比较 CPU 占用与吞吐。单次网页打开速度无法证明直接复制路径是否生效，也不能据此给出固定提速百分比。
四、导入后要逐项核对的字段
订阅通常会填入大部分参数，但更新过程中的字段丢失、手工编辑和内核版本差异仍可能导致失败。建议先保留原始导入记录，再逐项修改副本。一次只改一个字段，便于把日志变化与设置变化对应起来。
- 服务器地址与端口：必须指向代理服务实际监听位置。远端
443和客户端本地 SOCKS 监听端口不是同一项，不能互换。 - UUID 与 flow：UUID 对应服务端 VLESS 用户；客户端
flow应与该用户的服务端设置匹配。填入xtls-rprx-vision不能让未启用 Vision 的服务端自动支持它。 - 公钥：来自服务端 REALITY 私钥对应的公钥，不是网站证书文本。分享链接常用
pbk携带此值；图形界面和内核 JSON 的字段命名可能随版本变化，应按对应版本文档核对，不能直接把链接参数名照抄成 JSON 字段。 - SNI 与指纹：
serverName应落在服务端允许的名称范围内；fingerprint的示例值chrome描述 ClientHello 指纹，不会改变本机浏览器，也不等于隐藏所有网络特征。 - shortId：客户端值必须匹配服务端允许列表中的一项。它使用十六进制表示，最多 16 个字符且为偶数长度；只有服务端允许空值时，客户端才可以留空。
在 v2rayNG 中，可长按对应配置，进入「编辑」核对服务器地址、端口、传输安全、SNI 和公钥等项目；界面标签随版本可能略有不同。在 v2rayN 中，双击配置进入编辑窗口，并核对实际选用的内核。不要为了排障直接开启“允许不安全证书”一类选项，它不能代替 REALITY 公钥认证。
五、按握手、代理请求、应用访问分段排查
“节点连不上”包含多种不同故障。TCP 端口不可达时，修改 SNI 没有作用；REALITY 认证失败时，调整路由规则也无法补救。应按连接发生的先后顺序收集信息，而不是把所有参数重新随机填一遍。
- 先确认连接目的地：核对服务器地址、实际端口、服务端监听和防火墙规则。超时与连接被拒绝不是同一类结果，前者还可能涉及线路丢包或过滤。
- 再检查握手认证：对照公钥、SNI、shortId 与指纹设置。若服务端配置了握手时间差限制，还需确认两端系统时间同步，避免把时钟偏差误判成密钥错误。
- 然后检查 VLESS 用户：握手完成后仍失败，应继续核对 UUID、flow 和服务端用户配置。外层连接建立不代表代理请求已被接受。
- 最后检查应用链路：确认应用流量进入客户端，接着看 DNS、路由规则和服务端出站。仅有连接成功日志，不能证明浏览器已经走了该代理。
公钥和 UUID 都填了，为什么仍然握手失败？
先从原始订阅重新导入一份副本，逐项比对 SNI、shortId 和传输安全是否为 REALITY。再核对服务端公钥是否在更换私钥后同步更新，查看同一时间点两端日志，不要只凭延迟测试结果判断。
能连接但网页打不开，还要改指纹吗？
先确认浏览器使用系统代理或指定本地代理，检查请求是否出现在客户端日志中。若请求已经进入代理，再核对 DNS 解析与路由出口；没有握手错误时，不应优先反复切换指纹。
开启 Vision 后速度没变化，是设置没生效吗？
不一定。先核对两端 flow，再固定下载源与测试时段，观察 CPU 和吞吐。线路带宽、丢包或目标服务器限速都可能成为瓶颈；普通小网页也很难体现减少数据转发开销的收益。
为什么换到 v2flyNG 后同一订阅不能直接用？
先确认配置是否依赖 Xray 的 REALITY 与 Vision 功能。这类配置应在支持对应功能的 v2rayNG，或选用合适内核的 v2rayN 中使用；改一个客户端名称或传输标签不能解决内核能力差异。
六、理解适用边界，再决定是否更换配置
REALITY 不会隐藏代理服务器的 IP，也不能保证流量不可识别。目标站选择、服务端部署、网络路径与客户端版本都会影响实际表现。Vision 的价值主要在符合条件的数据流处理效率，而不是改变物理链路的带宽和往返时延；高丢包、拥塞和服务端负载仍需独立排查。
- 已有稳定配置时，保留原配置作为对照，不要同时更换服务端、传输方式和 DNS。
- 需要手工维护时，保存内核版本与字段变更记录，升级后先测试一条配置，再批量更新。
- 分享排错信息时，隐藏 UUID、订阅地址及服务端私钥；保留错误类型、时间点和必要字段名称。
- 继续阅读字段说明时，可查看本站 JSON 手册；首次导入与启用代理可按 入门指南 操作。
最终需要确认的不是界面上是否同时出现三个名称，而是完整链路能否成立：客户端连接正确的服务器，REALITY 认证通过，VLESS 用户与流控匹配，应用请求按预期路由到目标。把这几层分开，配置和排障都更容易复现。