REALITY 与 XTLS Vision 原理科普:少一层加密为何更快

先拆开三个名字：VLESS、REALITY 与 Vision

在 v2rayN 或 v2rayNG 中，常见节点组合是“VLESS + REALITY + XTLS Vision”。这不是三个可以互换的协议名。VLESS 描述代理请求如何携带用户身份与目标地址；REALITY 负责连接外层的安全握手与认证；Vision 是 Xray 的一种流控机制，决定部分数据如何在隧道内处理。把三个层次分开，才能知道报错应该从哪个字段查起。

VLESS 的 encryption 常见值是 none。它表示 VLESS 协议本身不再增加一套载荷加密，不等于整条连接明文传输。使用 REALITY 时，安全层仍参与连接建立；浏览器访问 HTTPS 站点时，应用自己的 TLS 加密也仍然存在。

HTTPS 经过代理，为什么会出现两层加密

浏览器打开 HTTPS 网站时，先与目标网站进行 TLS 握手。网页正文、登录信息和响应内容随后变成应用层的 TLS 密文。代理只是负责把这条连接送到目标网站，并不因此取得网站会话的解密密钥。

若代理隧道自己也使用 TLS，浏览器产生的密文会再被包装进代理连接的 TLS 记录。客户端加密一次外层，服务器解密一次外层，再把内层密文转发到网站。这种“双层包装”很常见，也有实际用途，但大流量场景会带来额外的加解密、缓冲区处理和数据拷贝成本。

Vision 的核心不是取消 HTTPS，而是识别内部 TLS 的阶段，在满足条件时改变后续数据的传递方式。对于识别到的 TLS 1.3 流量，它可以在合适阶段进入直接转发模式，让已经加密的应用数据不再重复经过外层 TLS 加解密。初始握手与必要的代理信息仍需要受到保护，并不是一连接成功就把所有数据裸发出去。

• 网站侧的加密保持不变：浏览器仍验证目标网站证书，代理不应要求用户关闭网站证书验证。
• 优化需要识别条件：不是所有 TCP 数据，也不是所有 TLS 版本，都能进入相同的优化路径。
• 普通 HTTP 不会变成 HTTPS：Vision 不会替应用补上与目标网站之间的端到端加密。
• 握手阶段还有填充：Vision 会对初始阶段的数据做填充处理，不能把它概括为“每个包都更小”。

REALITY 怎样借用真实站点的握手外观

普通 TLS 代理服务通常要准备自己的域名与证书。REALITY 采用另一种设计：服务端配置一个合适的真实 TLS 目标，客户端则携带约定的认证参数发起握手。对于能够通过认证的连接，客户端与 REALITY 服务端建立代理通道；对于没有通过认证的连接，服务端可把连接转交给配置的目标，让其表现为与真实站点的正常 TLS 交互。

“借用真实站点”是一种便于理解的说法，不代表掌握该站点私钥，也不代表代理的全部流量都先绕到那个网站。认证成功后的代理数据由服务器按目标地址转发；配置的真实站点主要参与握手外观、未认证连接处理等机制。客户端用于信任 REALITY 服务端的依据，也不是简单把目标网站的公开证书复制到本地。

地址、SNI 和真实目标是不同字段

• 服务器地址：客户端真正连接的代理服务器 IP 或域名，不能随意替换成作为握手目标的网站。
• SNI / Server Name：客户端在握手中使用的名称，必须符合服务端允许的名称。地址能连接，不代表这个字段正确。
• 服务端真实目标：由服务端维护者选择。应检查 TLS 1.3、HTTP/2 等适配条件，并关注从服务器访问目标的延迟与可用性。
• 客户端指纹：影响 ClientHello 的构造，例如 chrome。它不能替代正确的密钥、SNI 和身份参数，也不能保证与真实浏览器的所有行为完全一致。

在 v2rayN 与 v2rayNG 中核对哪些参数

优先从可信的订阅导入完整节点，再进入节点编辑页面核对字段。不同客户端版本的菜单名称会变化，但协议、传输、安全层和 Flow 的含义不变。下面两张卡展示的是同一连接两端的核对关系，不是可以直接复制使用的完整节点。端口 443 只是常见示例，必须以实际服务端监听端口为准。

REALITY 的密钥参数在客户端界面和不同 Xray 配置版本中可能采用不同名称。老配置常见 publicKey，较新配置可能使用 password。不要只看字段名字手动搬运 JSON，应按正在运行的内核文档与客户端导入规则处理。服务端私钥则始终不应发给普通使用者。

Short ID 采用十六进制字符串，非空时字符数应为偶数，最长 16 个字符。是否允许空值取决于服务端配置。它不是用户 ID，也不是随机填写的备注。若订阅中给出了 Short ID，就保持原值；擅自修改一个字符也可能导致认证失败。

少一层加密为何可能更快，又为何不一定更快

加密不是唯一成本，但在高吞吐连接中，它可能成为明显成本。Vision 减少符合条件的数据重复加解密，并在实现允许时利用更高效的传递路径，降低 CPU 占用和数据搬运负担。服务器处理多个大流量连接时，这种改进比短小的网页请求更容易体现。

如果瓶颈在移动网络丢包、服务器出口带宽、运营商拥塞或目标网站限速，减少一层加密未必能改变下载速度。TCP 的拥塞控制仍然存在，REALITY 也不会增加线路的物理带宽。不能从某个节点跑得快，直接推出“所有 REALITY 节点都比其他组合快”。

怎样做一次可比较的测试

1. 固定同一设备、网络、服务器与下载目标，关闭其他大流量任务，避免把 Wi-Fi 信号变化算成协议收益。
2. 使用服务端明确支持的两套测试配置，不要直接清空 Flow 字段作为对照；客户端与服务端的设置必须互相匹配。
3. 每组连续下载 60 秒，重复 3 次，同时记录平均吞吐、客户端 CPU、服务器 CPU 与连接错误。
4. 分别测试长文件和网页首开。若只有 CPU 降低而吞吐不变，说明优化有效，但当前速度瓶颈可能在其他位置。

连接失败时，按握手阶段排查

“握手失败”只说明安全连接没有完成，不自动指向证书问题。REALITY 的认证参数不匹配、SNI 不允许、服务端目标不可达、设备时间偏差，都可能产生连接失败。先区分 TCP 能否建立，再检查 REALITY 认证，最后检查 VLESS 用户与 Flow，通常比反复切换加密选项更有效。

1. 先看连接地址：确认客户端连接的是代理服务器，而不是握手目标。若日志显示连接超时或拒绝连接，检查监听端口、防火墙和网络可达性。
2. 再看系统时间：在 Windows 的“设置”→“时间和语言”→“日期和时间”检查自动时间与同步状态；安卓也应开启自动日期和时间。REALITY 可按服务端策略限制时间差。
3. 核对认证参数：逐项比对 SNI、客户端认证密钥参数和 Short ID。服务端更换密钥后，旧订阅即使地址没变，也可能无法继续使用。
4. 检查用户和 Flow：确认 VLESS 用户 ID 存在于服务端，且两端使用兼容的 Vision 设置。不要把 REALITY 安全层选项与 Flow 字段混为一谈。
5. 核对实际内核：确认 v2rayN 当前使用的是支持该组合的 Xray 内核。界面能保存节点，不意味着所选内核一定接受所有字段。
6. 最后查目标与转发：若握手已经成功但页面打不开，再检查服务端 DNS、出站路由、目标可达性，以及客户端是否把该流量送入代理。