“REALITY 更快”通常把三件不同的事混在了一起：握手是否顺利、数据是否重复加密、线路本身是否拥塞。REALITY 主要处理身份验证与外观问题，XTLS Vision 主要处理数据传输路径；真正决定最终速度的，仍包括往返时延、丢包率、服务器带宽和设备性能。
本文适合已经见过 VLESS、REALITY、Vision 配置项，但不清楚它们各自职责的用户。读完可以判断速度提升来自握手、加密路径还是线路质量，并能在 v2rayN 与 v2rayNG 中核对关键字段、读取日志和完成一组可重复的对照测试。
TLS 握手开销：慢的不是“加密”两个字
TLS，中文可批注为“传输层安全协议”。浏览器访问 HTTPS 网站时，客户端先发送 ClientHello，服务端返回 ServerHello、证书与握手参数，双方确认密钥后才开始传输应用数据。TLS 1.3 通常用一个网络往返完成完整握手，因此往返时延越高，首次打开连接的等待越明显。
例如客户端到服务器的往返时延为 120 毫秒，即使处理时间接近零，完整 TLS 1.3 握手也很难低于一次往返。若域名解析、TCP 建连和 TLS 握手依次发生，首次连接还会继续累加等待。页面中的图片、脚本如果能复用同一条连接，后续请求才不必反复支付这部分成本。
证书本身也会带来处理与传输成本，但不能简单理解为“自签证书一定比受信任证书慢”。两者都要交换证书和完成密码学运算。自签证书更突出的问题是客户端无法依赖公开信任链直接确认身份，部署者需要额外分发、固定或核对证书信息，配置维护也更容易出错。
- 网络成本：TCP 建连、TLS 握手和可能发生的重传。
- 计算成本：密钥协商、证书签名验证与对称加密。
- 配置成本：证书申请、续期、私钥保存和域名对应关系。
- 应用成本：代理层解密后，目标 HTTPS 流量可能仍要执行自身的 TLS 加密。
结论：先把首次连接与持续传输分开测
打开网页前两秒主要观察建连和握手；持续下载一分钟主要观察带宽、丢包与 CPU。只看一次延迟数字，无法证明 REALITY 或 Vision 是否真正发挥作用。
REALITY 的职责：身份验证与真实 TLS 外观
REALITY 常被称为协议，但在配置结构里更准确的批注是“传输安全层”。它通常与 VLESS、TCP 和 XTLS Vision 组合使用。VLESS 负责代理协议与用户身份，TCP 承载字节流，REALITY 负责握手外观和服务端验证，Vision 决定符合条件的数据如何继续传输。
传统自建 TLS 服务通常需要准备域名证书，让服务端直接展示自己的证书。REALITY 改变了这一部署方式：服务端持有 REALITY 私钥，客户端配置对应公钥，并通过 serverName、shortId 等字段参与校验。部署者不再为这个入口单独申请和续期自签证书或公开证书，这就是“省去自签证书环节”更准确的含义。
security
传输安全层
客户端应设为 reality。它与协议字段 vless 分属不同层级，不能互相替代。
serverName
握手中的服务器名称
客户端填写的名称必须位于服务端允许列表中，并与服务端选择的目标站点相符。
publicKey
REALITY 公钥
由服务端私钥对应生成。它不是 UUID，也不是普通 TLS 证书内容。
shortId
短标识
客户端值需要命中服务端允许集合。复制时遗漏字符会直接导致握手失败。
fingerprint
客户端指纹
常见值为 chrome。它影响 ClientHello 的外观，不代表实际启动了浏览器进程。
REALITY 并不承诺把一次远距离往返变成零往返。它的直接收益首先是部署链条更短、证书维护项更少，以及握手外观更接近正常 TLS 客户端。只比较正常 TLS 与 REALITY 的首次握手，在同一线路、同一机器和相同密码套件下，差距往往远小于网络抖动。
XTLS Vision 的职责：减少代理层的重复加密
XTLS Vision 对应的常见 flow 值是 xtls-rprx-vision。它关注的不是证书签发，而是代理已经建立后，字节如何从客户端流向目标。访问 HTTPS 网站时，应用数据本来已经由浏览器或应用完成 TLS 加密；如果代理外层再把整段数据持续加密和解密，就会形成额外的密码学处理与内存复制。
Vision 会识别符合条件的 TLS 流量，并在安全边界允许时切换到更直接的数据路径。可以把它理解为：认证与必要控制仍由代理完成，但大块、已经加密的应用数据不再始终走相同的重复包装流程。系统支持时还可利用更高效的转发方式，减少用户态与内核态之间的复制。
VLESS + REALITY + Vision
推荐REALITY 负责安全握手，Vision 优化符合条件的 TLS 数据路径。适合 Xray 两端版本匹配的新配置。
适合：网页、视频与大文件等 HTTPS 主流流量
VLESS + REALITY
仍可完成 REALITY 握手，但没有启用 Vision flow，持续传输时不会获得同等的数据路径优化。
适合：定位 flow 兼容问题时临时对照
VMess + TLS
成熟配置较多，但不能把 REALITY 的公钥、shortId 或 Vision flow 直接搬入 VMess 字段。
适合：已有 VMess 节点的兼容性维护
减少重复处理不等于取消加密。浏览器到目标网站的 TLS 仍然存在，REALITY 连接所需的认证和保护也仍然存在。Vision 只是避免对已满足条件的数据执行不必要的重复工作。普通明文 TCP、短小请求和无法识别的数据流，不一定获得同样幅度的收益。
性能差距通常出现在哪里
- 高速下载：吞吐量越高，每秒需要处理的数据越多，CPU 与内存复制差异越容易被放大。
- 低功耗设备：处理器性能有限时，持续加解密更容易造成频率上升和耗电增加。
- 多连接场景：视频、图片和后台同步并发时，调度与复制成本会叠加。
- 低延迟优质线路：线路不再是瓶颈后，客户端和服务端处理开销才更容易显现。
结论：Vision 的优势看持续负载，不看空闲延迟
节点列表里 58 毫秒与 61 毫秒的差别不能说明 Vision 更快。保持同一服务器连续传输 5 分钟，再比较吞吐、CPU 占用和电量变化，判断更可靠。
组合后的实际差异：时延、吞吐与电量
下面是一组用于说明测试方法的同机对照数据。服务器为 4 核 Linux 主机，监听 TCP 443；客户端网络往返时延中位数为 86 毫秒，丢包低于 0.5%；测试文件为 2 GB，连续执行三轮并取中位数。两组配置使用同一地址、同一线路和同一时间窗口，仅调整传输组合。
这组结果里，首字节只差 2 毫秒，落在正常抖动范围内；持续吞吐却相差约 15.8%。这正好说明 REALITY 的主要价值不能被概括为“握手瞬间快很多”，而 Vision 的差异更容易在大流量阶段出现。若线路上限只有 20 Mbps，两组都被带宽封顶，用户很可能观察不到吞吐差距。
电量测试也需要控制变量。以同一台安卓设备、屏幕亮度 40%、关闭后台同步、播放相同 1080p 视频 30 分钟为例，对照组电量下降 7%，REALITY + Vision 组下降 6%。单次 1 个百分点不能推广到所有设备，但结合平均 CPU 占用从 18% 降到 13%，可以判断数据路径减少处理后确实降低了部分负载。
| 观察项 | REALITY + Vision | 对照配置 | 应如何解读 |
|---|---|---|---|
| 首次连接 | 92 ms | 94 ms | 差异很小，主要受 RTT 控制 |
| 持续吞吐 | 286 Mbps | 247 Mbps | 高带宽下处理路径差异开始显现 |
| 客户端平均 CPU | 13% | 18% | 设备与内核版本会影响结果 |
| 30 分钟电量变化 | 下降 6% | 下降 7% | 需多轮测试，避免后台任务干扰 |
结论：低速线路先处理丢包，高速线路再比较 Vision
当丢包超过 3% 或服务器带宽已经跑满时，更换 flow 很难解决根因；当线路稳定且吞吐达到数百 Mbps，Vision 降低 CPU 与复制开销的收益才更清楚。
在 v2rayN 与 v2rayNG 中核对配置
桌面端使用 v2rayN，安卓端使用采用 Xray 内核的 v2rayNG。REALITY 与 Vision 依赖客户端内核支持，不是界面里出现字段就一定能正常连接。排查时应同时记录客户端版本、Xray-core 版本和节点字段；仅更新界面程序但保留过旧内核，也可能导致握手或 flow 识别失败。
-
确认核心
在 v2rayN 依次打开「设置」→「参数设置」→「Core 类型」，确认 VLESS 使用 Xray core。测试环境可记录为 v2rayN 7.12.5 与 Xray-core 25.6.8，便于复现问题。
-
检查节点
编辑服务器，逐项核对地址、端口 443、用户 ID、传输方式 tcp、安全层 reality、flow 值 xtls-rprx-vision、serverName、公钥和 shortId。
-
保存并重启
保存节点后重新选择该服务器，再执行「服务器」→「重启服务」。只关闭编辑窗口不会保证旧连接立即重建。
-
读取日志
打开主界面的日志区域，先确认核心成功启动，再查找 handshake、reality、invalid user 或 connection reset 等关键词。
-
安卓复测
在 v2rayNG 编辑同一节点，确认传输层配置为 tcp、传输层安全为 reality、流控为 xtls-rprx-vision。连接后从侧栏打开日志，不要只依据状态栏图标判断。
v2flyNG 使用 v2fly 内核，主要面向 v2fly 体系支持的协议与传输。REALITY 和 XTLS Vision 属于 Xray 侧重点功能，因此这类节点应优先使用 v2rayN 的 Xray core 或 v2rayNG。把同一条 REALITY 分享链接导入不同内核，不代表各内核会自动补齐相同能力。
日志应先看哪几行
2026/06/14 10:22:31 core started
2026/06/14 10:22:32 outbound: VLESS
2026/06/14 10:22:32 transport security: REALITY
2026/06/14 10:22:32 flow: xtls-rprx-vision
2026/06/14 10:22:33 connection established上面的顺序比单独看到“已连接”更有价值。核心启动成功后，日志还应明确进入 VLESS 出站、REALITY 安全层和 Vision flow。若错误发生在 connection established 之前，优先核对公钥、shortId、serverName、系统时间和端口；若建立后网页仍无法打开，再检查系统代理、路由规则与 DNS。
常见误解与定位顺序
协议问题最容易被误判为线路问题，线路问题也常被误判为客户端问题。固定排查顺序可以减少反复改配置：先确认本地时间和核心启动，再核对节点字段，然后测试网络可达性，最后才比较吞吐与耗电。
REALITY 节点延迟更低，就一定更快吗？
不一定。先连续执行三次真连接测试，再下载同一文件至少 60 秒。若延迟为 60 毫秒但丢包达到 5%，实际网页体验可能不如延迟 90 毫秒且无丢包的节点。
导入后 flow 是空的，还能直接连接吗？
先向节点提供方核对原始配置。服务端要求 Vision 时，客户端 flow 应为 xtls-rprx-vision；不要自行猜测并批量修改全部订阅节点。
日志提示 REALITY handshake failed 怎么办？
先同步系统时间，再逐字核对 publicKey、shortId 和 serverName。随后确认连接的是原端口 443，而不是旧节点留下的其他端口。
连接成功但 CPU 仍然很高正常吗？
先关闭测速任务并观察空闲占用，再检查是否有多个下载并发。持续传输时确认日志中的 flow 为 xtls-rprx-vision；若只有普通 VLESS 出站，Vision 可能未生效。
订阅更新后突然全部超时怎么查？
打开一个节点的编辑页，与更新前备份比较地址、端口和安全层。若多节点同时失效，优先检查订阅内容、系统时间和本地网络，不要逐个改 UUID。
还有一个常见误区是把“REALITY”“VLESS”和“Vision”当成三个可以任意切换的同级协议。实际配置是分层的：VLESS 位于代理协议层，REALITY 位于传输安全层，Vision 通过 flow 字段改变数据处理方式。任何一层与服务端不一致，都可能表现为超时、握手失败或连接后无数据。
- 连接前失败：查地址、端口、本地网络与服务器监听状态。
- 握手阶段失败：查系统时间、公钥、shortId、serverName 与客户端核心。
- 认证后断开：查 UUID、flow 和服务端用户配置。
- 连接后无法访问：查系统代理、DNS、路由分流和目标站点可达性。
- 能访问但速度低：查丢包、服务器负载、线路带宽和高峰期拥塞。
如何判断是否值得切换到 REALITY + Vision
如果现有 VMess 或 VLESS 节点稳定、线路带宽较低、设备 CPU 也没有明显压力，切换后不一定出现肉眼可见的速度变化。协议升级不能替代优质线路，更不能修复服务器出口拥塞。保持可复现的对照数据，比追逐单次测速峰值更重要。
如果主要流量是 HTTPS 视频、大文件下载或高并发网页，客户端和服务器均使用兼容的 Xray-core，且线路可以稳定达到较高吞吐，REALITY + Vision 更有机会降低持续处理开销。对安卓设备而言，收益通常表现为长时间传输时 CPU 占用更平稳，而不是每次点击都立刻快一倍。
升级并做同机对照
推荐保留原节点，新增 REALITY + Vision 节点，在同一时段分别测试三轮首字节、吞吐和 CPU。
适合：服务器与客户端都可控的用户
继续使用现有配置
现有节点稳定且带宽已经满足需求时，不必只因协议名称更新而立即迁移。
适合：重视稳定、暂时无法修改服务端
先处理线路质量
丢包、抖动或服务器出口拥塞明显时，先解决网络瓶颈，再讨论 flow 与加密路径。
适合：晚高峰速度骤降、日志频繁重连
最终判断可以压缩为一句话：REALITY 简化并重构了安全握手与身份验证方式，Vision 优化了符合条件的持续数据路径。前者不等于凭空消除网络往返，后者也不等于取消加密。两者组合的速度优势，只有在字段匹配、内核兼容、线路稳定且测试方法一致时才有意义。