VLESS 负责代理协议与用户身份，REALITY 处理连接的握手与认证，XTLS Vision 调整流量封装方式。本文面向准备导入或手动配置 REALITY 节点的用户，说明三者的分工、性能收益的前提，以及 v2rayN 中地址、SNI、公钥、Short ID 和 Flow 的对应关系。
VLESS、REALITY 与 Vision 各负责什么
节点名称里的“VLESS + TCP + REALITY + Vision”不是四个同义词，也不是四种加密叠加。把它们拆成不同层次，才能理解为什么同样标注 VLESS 的两个节点，配置项和连接表现可能完全不同。
- VLESS：代理协议，携带用户标识、目标地址等信息。常用 UUID 标识用户；协议本身不承担类似 TLS 的内容加密职责。
- TCP：这里采用的底层传输。较新的 Xray 配置与部分界面也会使用 RAW 名称，具体按客户端与内核的字段说明识别。
- REALITY：Xray 生态中的传输安全机制，涉及握手、服务端身份验证，以及对未通过认证连接的处理。
- XTLS Vision：VLESS 的流控方案，对应常见 Flow 值
xtls-rprx-vision，用于调整早期数据形态，并在满足条件时减少重复封装与加密。
v2rayN 是管理界面，实际建立连接的是它启动的内核。讨论这组参数时，应确认当前节点由支持相应功能的 Xray 内核处理，而不是只看客户端窗口能否打开。V2Fly 与 Xray 的功能演进并不完全一致，不能因为二者都源于 V2Ray 技术体系，就直接互换同一份 REALITY 配置。
REALITY 握手：地址、SNI 与认证信息
浏览器访问 HTTPS 网站时，会先协商 TLS 参数并验证对端身份。代理连接又在浏览器与网站之间增加了一段客户端到代理服务器的链路。REALITY 主要处理的是这段链路，而不是替浏览器签发目标网站证书。
REALITY 客户端使用服务端提供的公钥等参数验证连接，并在握手过程中携带相应认证信息。服务端还会检查配置允许的服务器名称、Short ID 等条件。未通过认证的连接可按 REALITY 的机制转向服务端配置的目标站点；具体行为取决于配置及失败发生的阶段，不能理解为任何报错都一定会打开一个网页。
这里有两个容易混淆的地址：节点“地址”决定客户端连到哪台代理服务器；SNI，即服务器名称，是握手中的名称参数，通常必须属于服务端允许的名称集合。把 SNI 直接填成节点 IP，或把节点地址换成 SNI 对应的网站地址，都可能破坏原有配置。
- 节点地址与端口：由节点提供方给出。使用
443很常见，但它只是端口约定，不代表其他端口不能运行。 - 服务器名称：对应
serverName；分享链接中常见参数名为sni，应原样保留。 - 公钥：必须与服务端私钥对应。客户端只需要连接所需的公钥信息，不应索取或填写服务端私钥。
- Short ID：是服务端允许的短标识，不是 UUID 的截取值，也不是随意生成的备注。
- 指纹：常见值为
chrome，用于选择客户端握手特征，不会把应用实际使用的浏览器改成 Chrome。
REALITY 不要求站点管理员为这段代理链路按传统方式配置自己的域名证书，但服务端目标站点的选择与可达性仍然重要。它也不能保证流量在所有网络环境中不可识别；握手之外，连接持续时间、包长和访问行为仍属于网络可观察信息。
XTLS Vision 为什么可能减少开销
常规 TLS 代理承载 HTTPS 时，会出现两层保护：浏览器与目标网站之间已有一层 TLS，客户端与代理服务器之间又套一层 TLS。这不意味着内容有问题，但外层重复处理会消耗计算资源，并增加记录封装与数据复制等开销。
Vision 会识别被代理连接的早期数据，在前期使用填充等方式调整数据形态；对符合条件的 TLS 流量，尤其是可识别的 TLS 1.3 连接，可以在适当阶段切换数据处理方式，避免始终对已加密的应用数据再做同样的外层加密。浏览器与目标站点之间的 TLS 仍然存在。
这里的“更快”有明确边界。如果服务器加密处理或数据转发已经接近 CPU 上限，减少重复处理更可能带来收益；如果瓶颈是跨境线路拥塞、服务器限速或丢包，换成 Vision 也不会凭空增加带宽。非 TLS 流量与不符合优化条件的连接，不能套用同样的收益预期。
判断方法：同时看吞吐与 CPU
在同一服务器、同一目标文件和相近时段比较下载表现，同时记录 CPU 占用。只有吞吐改善或同等吞吐下 CPU 降低，才能支持“开销减少”的判断；单次延迟测试不能证明 Vision 更快。
v2rayN 配置项：按服务端参数逐项对应
优先导入完整的订阅或分享链接，再检查关键字段。v2rayN 桌面不同版本的菜单文字可能略有差异，常见操作是复制分享链接后，通过「服务器」→「从剪贴板导入批量 URL」导入，再打开对应条目的编辑窗口。不要仅凭节点名称包含 REALITY 就认定字段已经完整。
VLESS 与传输字段
- 协议
- VLESS
- 用户 ID
- 服务端分配的 UUID
- 加密
- 常见组合为 none
- 传输
- TCP / RAW，按版本界面对应
- Flow
xtls-rprx-vision
本卡描述常见 REALITY + Vision 组合，不应覆盖提供方另有说明的配置。
REALITY 握手字段
- 传输安全
- reality
- SNI
- 服务端允许的服务器名称
- 公钥
- 服务端提供的 REALITY 公钥
- Short ID
- 服务端允许的十六进制标识
- Fingerprint
- 例如 chrome，按原配置保留
公钥在不同版本中可能显示为 Public key 或 Password 等标签，应结合内核与导入结果核对。
VLESS 的 none 是该字段在这类组合中的常见取值，不表示整段链路以明文传输。这里的保护来自所选的传输安全机制。反过来，手动把它改成 VMess 常见的 auto，也不是“加密更强”的升级方式，而是混淆了不同协议的字段。
- 先核对地址、实际端口和 UUID，再核对传输、安全类型与 Flow；这些字段决定连接能否走到预期协议分支。
- 随后逐字核对 SNI、公钥和 Short ID，注意复制时的空格。Short ID 若非空，应为偶数个十六进制字符，长度不超过 16 个字符；是否允许空值由服务端决定。
- 确认该条目实际使用支持 REALITY 与 Vision 的 Xray 内核，然后设为活动服务器。不要把“界面保存成功”当作“内核已经支持”。
- 在「设置」→「参数设置」中核对本地监听端口，再选择「系统代理」→「自动配置系统代理」。若当前版本文字不同，按对应功能项查找。
性能对比：先固定条件，再讨论协议差异
比较不同订阅里的两个节点，往往首先比较到的是线路与服务器资源，而不是协议本身。一个低负载的普通 TLS 节点，完全可能快过一个拥塞的 REALITY 节点。要判断 Vision 的影响，应尽量只改变流控方案，并确保两套服务端配置都有效。
| 测试项目 | 建议方法 | 能说明什么 |
|---|---|---|
| 连接建立 | 同一 HTTPS 地址，分别建立 5 次新连接 | 观察握手与首个响应的稳定性 |
| 持续吞吐 | 同一较大文件，每轮至少 60 秒，交替测试 3 轮 | 减少瞬时突发与时段差异的干扰 |
| 资源占用 | 记录客户端与服务端测试期间的 CPU 占用 | 判断重复处理是否构成瓶颈 |
| 网络条件 | 保持同一接入网络、路由规则与目标站点 | 避免把直连、代理或线路差异混为协议收益 |
上表是测试方法，不是本站实测成绩。记录速度时还要区分单位：100 Mbps 的理论换算约为 12.5 MB/s，实际应用吞吐会受到协议开销和线路状态影响。如果路由规则让测试域名走了直连，结果就不能用于评价 REALITY。
- 网页首开慢、后续下载快：优先检查 DNS、握手耗时与目标站点响应。
- 下载速度逐渐下降且 CPU 接近满载：检查内核资源占用、设备性能和其他后台任务。
- 高峰期所有节点都慢：优先比较不同线路与时段，不要反复修改公钥或 Flow。
REALITY 连接失败的常见问答
端口测试正常，为什么网页还是打不开？
TCP 端口连通只说明目标端口可建立连接，不说明 REALITY 认证通过。先查看内核日志，再按地址、SNI、公钥、Short ID、UUID 的顺序与原始订阅核对；若出现认证相关错误，继续换 DNS 通常不能解决。
日志提示 Flow 不支持，要把它清空吗？
先检查实际运行的内核及版本，再确认服务端是否要求 xtls-rprx-vision。服务端要求 Vision 时，清空 Flow 不能替代正确配置。完成内核更新或切换后，重启核心并重新观察日志。
Short ID 可以随便填 16 个字符吗？
不可以。16 个十六进制字符只是长度上限，对应 8 字节；填入值还必须属于服务端允许的集合。不要把节点备注、UUID 片段或普通单词写进去，最稳妥的操作是重新导入提供方给出的完整链接。
已经选了节点，浏览器却没有经过代理？
先检查「系统代理」是否已配置，再核对浏览器是否使用系统代理，以及目标域名的路由规则。若本地 HTTP 代理监听端口设为 10808，浏览器手动配置也必须指向相同端口；同时查看日志中是否出现该次请求。
同一份配置在两台设备上表现不同怎么办？
对照内核版本、设备系统时间和实际网络。握手认证可能受时钟偏差影响，应先启用系统自动校时。随后在相同网络下复测，避免把一台设备的网络阻断误判为 UUID 或公钥错误。
配置顺序：先接通，再验证优化收益
REALITY 与 Vision 的价值分别落在握手机制和数据处理路径上。配置时先保证认证参数匹配，再确认应用请求确实进入代理，最后才比较性能。这样可以把握手失败、路由分流问题和带宽瓶颈分开处理，而不是在一次排查中同时改动十几个字段。
- 完整导入：保留提供方的地址、身份与握手参数，避免从截图拼装信息。
- 确认内核：使用支持该组合的 Xray 内核，遇到字段不识别时先排查版本。
- 验证路径：检查系统代理、本地监听与路由，确认目标请求经过该节点。
- 记录对比：用同一目标、相近时段和多轮测试判断收益，不把延迟数字当作下载速度。
需要了解订阅导入与系统代理的基本操作，可继续阅读使用文档；需要区分协议、传输与路由规则，可查看进阶手册中的协议说明。理解这些边界，比仅凭节点名称选择“更新的协议”更有助于稳定配置。