REALITY 负责连接的安全握手与认证，XTLS Vision 负责优化符合条件的数据转发，两者不是同一个开关。本文适合已经拿到 VLESS 订阅、需要理解配置字段的用户：先区分协议分工，再核对 flow、服务器名称、公钥与 shortId，最后用日志和受控测试判断问题，不把测速变化直接归因于“少加密一层”。
REALITY、VLESS 与 Vision 分别解决什么问题？
三者处在不同层次，可以组合使用，但不能互相替代。VLESS 提供代理请求与用户身份信息，本身不负责对载荷做通用加密；REALITY 提供安全握手与认证机制；Vision 则是 XTLS 的流控方案，关注 TLS 流量的识别、填充和后续转发路径。
常见的 VLESS + REALITY + Vision 节点通常使用 TCP 传输。客户端把浏览器发出的连接交给本地代理入口，再由内核建立到代理服务器的连接，服务器最终连接目标网站。这里至少存在“客户端到代理服务器”和“浏览器到网站”两个不同的安全上下文，不能把它们混成一次握手。
实际承担这些能力的是内核，不是客户端名称。v2rayN 是桌面管理界面，使用这类节点时应确认选用了支持对应功能的 Xray 内核；安卓上的 v2rayNG 使用 Xray 内核。v2flyNG 使用 v2fly 内核，不能仅因同样能导入 VLESS，就推断它能运行 Xray 的 REALITY 与 Vision 组合。
- 协议层：订阅中的 VLESS 与用户 ID 决定代理请求的组织和身份识别。
- 安全层：REALITY 与服务器提供的公钥、服务器名称等参数共同参与连接建立。
- 流控层：
xtls-rprx-vision必须得到客户端和服务端共同支持。 - 传输层：常见配置使用 TCP；部分界面或配置文档也称其为 RAW，应结合当前内核字段理解。
“TLS 套 TLS”为什么会带来额外开销？
重复保护已经加密的 HTTPS 数据，会增加代理这一层的处理工作。浏览器访问 HTTPS 网站时，应用数据已经经过网站 TLS 会话加密；传统 TLS 代理隧道又把这段密文封装进另一层 TLS。外层不需要理解网页内容，但仍要处理记录封装、加解密、缓冲和数据传递。
Vision 的关键不是关闭网站加密，而是在识别到符合条件的内层 TLS 流量后，切换后续数据的转发方式，避免继续把这部分已加密数据完整地包进外层 TLS 记录。它还包含前期填充等处理，因此不能简化为“从连接开始就直接裸转发所有内容”。
| 观察项 | 常规 TLS 隧道 | Vision 的条件性优化 |
|---|---|---|
| 网站 HTTPS | 浏览器与网站之间保持 TLS | 浏览器与网站之间仍保持 TLS |
| 代理外层处理 | 持续封装内层数据 | 满足识别条件后切换转发路径 |
| 数据搬运 | 通常经过 TLS 处理缓冲 | 部分平台可进一步利用 splice 等机制减少拷贝 |
| 非 TLS 载荷 | 由隧道提供保护 | 不会因为启用 Vision 就一律去掉外层保护 |
减少拷贝与减少加密不是完全相同的事。内核实现、操作系统、连接类型都影响能否走到更直接的数据路径；“使用 Vision”不等于每个连接都实现零拷贝。特别是 TLS 1.3 等符合条件的内层连接，才是理解这类优化的重点，不能据此推断所有 UDP、视频或下载任务都会同比提速。
判断：先确认瓶颈，再比较吞吐
如果下载时服务器 CPU 已接近满载，减少重复加密可能有实际价值；如果 CPU 仍有余量而链路拥塞、丢包明显，应先排查网络路径。只比较一次测速峰值，无法证明 Vision 带来了性能提升。
REALITY 为什么不需要自有域名证书？
REALITY 使用不同于普通网站证书部署的认证方式，因此服务端通常不必为这条代理连接申请、续期自己的域名证书。服务端持有私钥，客户端使用与之匹配的公钥等参数验证连接；这不等于“没有认证”，也不等于随意填写一个网站名称就能建立连接。
服务端还会配置目标站点与允许的服务器名称。对于未通过认证的连接，REALITY 可以按其机制把连接导向配置的目标站点；合法客户端则完成相应认证。目标网站应满足部署要求，常见基线包括 TLS 1.3 与 HTTP/2 支持，但“浏览器能打开”本身不是完整的兼容性证明。
公钥通常以编码后的文本显示，所以不能拿“32 字节”要求输入框只保留 32 个字符。公钥与私钥成对生成，服务端私钥不应复制到客户端；客户端也不应自行生成一个新公钥替换订阅提供的值，否则双方不再匹配。
v2rayN 里 flow、公钥和 shortId 怎么填？
优先完整导入订阅，再与提供方参数逐项对照，通常比手工拼接更可靠。在 v2rayN 主窗口选中节点后，双击打开编辑窗口，检查 VLESS 节点的传输、安全与流控字段；不同界面版本的中文标签可能不同，应以字段含义为准，不要为了找到同名菜单而改动无关设置。
下面两张卡描述同一节点的两组设置，不是可直接连接的示例账号。端口 443 只是常见示例，实际端口、用户 ID、公钥、shortId 和服务器名称均须来自同一份服务端配置。
协议与传输
- 协议
- VLESS
- 加密
- none
- 传输
- TCP / RAW，依界面标注
- Flow
xtls-rprx-vision
flow 与服务端保持一致；VLESS 的 none 不代表整条连接没有安全保护。
REALITY 安全参数
- 安全
- reality
- 服务器名称
- 服务端允许的 SNI
- 公钥
- 服务端私钥对应的客户端公钥
- Short ID
- 服务端允许的 shortId
- 指纹
- 按订阅指定，例如 chrome
这些值需要配套使用，不能从不同节点各复制一项组成新配置。
- flow：常见值为
xtls-rprx-vision，拼写和连字符必须准确。不要把旧教程里的其他 flow 值直接替换进来，也不要给不使用 Vision 的节点强行添加。 - 公钥：分享链接中常见参数名是
pbk。不同代际的内核或界面可能使用publicKey、password等标签承载相应值，应核对当前版本说明，不要在原始配置中同时盲填多个字段。 - shortId：通常为偶数长度的十六进制文本，最长 16 个十六进制字符。空值只有在服务端允许时才可用；它不是随便填写的“节点备注”。
- 指纹：
chrome表示一种握手指纹选项，不要求必须用对应浏览器访问，也不会替用户安装浏览器。
保存之后，要重新选择该节点并让内核重新加载配置。只改了节点列表中的记录、却没有更新正在运行的出站，可能让日志看起来与编辑窗口互相矛盾。安卓上的 v2rayNG 可从节点编辑页面核对对应字段，再从主界面的日志入口确认启动结果。
连接失败与速度没变，分别怎样排查？
先判断连接停在哪一步，再考虑性能优化。握手没有完成时，调整 Vision 的预期吞吐没有意义；网站已经能正常打开时，也不应因为测速没涨就判定公钥错误。建议每次只改一项，并保留修改前的节点记录，避免把可回退的配置一并覆盖。
- 检查内核能否启动：先看日志中是否有未知字段、非法 flow、配置解析失败等错误。这一阶段优先核对内核类型和配置格式，而不是更换 DNS。
- 检查地址和端口：确认实际连接的地址、端口与订阅一致。端口能建立 TCP 连接，只说明网络入口可达，不代表 REALITY 认证成功。
- 检查认证参数：对照用户 ID、公钥、shortId、SNI，并确认系统日期时间正常。握手错误可能有多种原因，不能仅凭一句连接关闭就断言是公钥错误。
- 检查应用是否进入代理：浏览器、终端与其他应用不一定使用同一入口。先看日志是否出现相应目标请求，再排查系统代理或应用自己的代理设置。
- 最后检查路由与解析：若代理连接成功但某个域名失败，应继续看 DNS、分流规则和目标网站可达性；这不一定是 REALITY 或 Vision 的问题。
需要比较性能时，应固定服务器、目标文件、网络接入和并发数，分别记录客户端与服务端 CPU 占用、持续吞吐和失败情况。例如每组运行 3 次、每次 60 秒，观察中间稳定区间而非最初的瞬时峰值；这是一种测试安排，不是本文提供的实测结果。
操作：用配套配置做对照，不只清空 flow
如果要比较有无 Vision，应由服务端提供两套都能正常工作的对照配置。只在客户端删除 flow，可能破坏双方约定，得到的连接失败或速度变化没有比较价值。
几个容易混淆的配置问题
大多数误区来自把“功能支持”“认证通过”和“应用走代理”混为一件事。按下面的问题核对，通常能缩小排查范围；需要进一步检查分流时，可继续阅读站内的进阶配置说明。
开了 REALITY，还要把允许不安全打开吗？
不要用“允许不安全”绕过 REALITY 参数错误。保持正常验证设置，回到节点编辑窗口核对公钥、SNI 和 shortId；相关开关不能修复双方密钥不匹配的问题。
订阅能导入，为什么仍提示不支持 flow？
能解析分享链接，不代表当前运行内核支持全部字段。先从启动日志确认实际内核，再核对其对 REALITY 和 Vision 的支持；不要仅凭客户端显示了 VLESS 图标判断兼容性。
用了 Vision，普通 HTTP 会明文穿过整条代理链吗？
Vision 不会把所有载荷都切成直通。非 TLS 内容仍需相应外层保护，但普通 HTTP 在代理服务器到目标网站这一段仍可能是明文；涉及账号或敏感信息时，应使用目标网站的 HTTPS。
同一个节点，终端打不开但浏览器正常怎么办？
先检查终端是否配置了代理入口，并用客户端实际监听端口测试。浏览器能用只证明其请求路径可用，不能证明终端也读取了系统代理；此时不要先改公钥或更换 flow。
能不能把现有 WebSocket 节点直接改成 Vision？
不能只改客户端字段。传输方式、服务端入站与 flow 都需要配套支持；应取得提供方给出的完整节点配置，而不是保留原有 WebSocket 路径后自行添加 Vision。
选择节点时，先看提供方给出的完整参数与内核要求，再看是否适合当前网络。REALITY 减少了自有证书的部署负担，Vision 为符合条件的 TLS 流量提供更高效的转发路径；两者都不能代替可靠的服务器、正常的网络链路和准确的客户端配置。