Reality协议是什么？抗主动探测的原理和落地细节

Reality协议是什么？一句话：它不给你的流量套一层"加密隧道"的外衣，而是让你的连接从握手第一个字节起就长得跟访问一个真实的大网站一模一样。理解这一点，就能明白为什么传统协议在强干扰网络下会成批失效，而它还能连上。

传统协议栽在哪一步

L2TP/IPsec、SSTP、PPTP 这些协议的共同问题不是加密强度不够，而是特征太明显。它们有固定的端口、固定的握手包结构，识别设备不需要解密，光看流量形状就能判定"这是一条 VPN 连接"，然后直接阻断。

后来出现的一批协议改用 TLS 伪装：把流量包装成 HTTPS 的样子。这一步挡住了被动识别，却挡不住主动探测——识别设备记下你连接的服务器地址，回头自己去连一次。如果对方返回的不是一个正常网站该有的响应，那就暴露了。很多"看起来像 HTTPS"的方案就是死在这一关。

Reality 怎么做到"探测过去也是个正常网站"

Reality 的思路是不再自己伪造证书，而是借用一个真实存在的网站：

1. 客户端发起握手时，SNI 填的是某个真实的大流量网站域名；
2. 服务端在握手过程中把该真实网站的证书原样转给客户端，所以客户端看到的证书是真证书，能通过任何证书校验；
3. 服务端靠一段只有合法客户端才有的密钥材料来分辨来者身份；
4. 分辨不出来的，一律当成普通访客，把这次连接原样转发给那个真实网站。

关键就在第 4 步。主动探测者去连这台服务器，拿到的是那个真实网站完完整整的响应——证书是真的、内容是真的、行为是真的。从探测者的视角，这台机器就是一个普通的反向代理，没有任何"可疑"可言。

需要说明的是，传统协议并非一无是处。在企业内网、没有强干扰的网络环境里，L2TP/IPsec 这类协议设备原生支持、不用装客户端，反而更省事——可以对照L2TP/IPsec怎么设置：填字段与排错和SSTP适合什么场景这两篇判断。协议没有绝对优劣，只有场景匹配。

光有协议还不够：伪装域名不能只有一个

Reality 的强度建立在"借用的那个域名看起来正常"之上。如果整个服务商的所有线路都借用同一个域名，那么这个域名一旦被针对性处理，全部线路会同时失效——协议再强也救不了。所以"Reality协议稳不稳"这个问题，答案不在协议本身，而在服务端怎么排布伪装域名。

我们的做法是单台服务器配置 30 个以上不同伪装域名的入站，每条线路随机分配其中一个。某个伪装域名出问题，只影响恰好用到它的少数线路，其余线路完全不受影响。用户侧还可以自助"更换伪装域名"，从服务器已有的其它域名里换一个，不需要重新申请线路、不需要改客户端配置。

再强的单一通道也要有备份

Reality 走的是 TCP。TCP 这条路整体受到干扰时，换域名也没用，这时需要的是另一条物理上独立的通道。

我们内置了 Hysteria2 作为备用协议：基于 QUIC/UDP，与主协议走完全独立的传输层，自定义证书加流量混淆，在客户端里一键切换，不用重新申请线路。TCP 通道和 UDP 通道互不影响，一个被干扰，另一个照常工作。Telegram 用户还有第三条路——MTProto 专线，那是专为 Telegram 设计的另一套伪装机制，与前两者同样互相独立。

遇到连不上时，按这个顺序处理

协议原理讲完，落到实际操作上其实很简单，从代价最小的往下试：

1. 先切协议：在客户端一键切到 Hysteria2。如果立刻好了，说明是 TCP 方向的问题，不用再折腾别的。
2. 再换伪装域名：协议切换无效时，说明问题可能出在当前线路用的那个伪装域名上，自助换一个。
3. 跑一次分层诊断：客户端会依次检测本地代理端口、线路配置、传输层握手、实际访问，直接给出具体故障结论，而不是笼统的"连接失败"。知道卡在哪一层，才知道该修哪里。
4. 用一键自助修复：确认是线路侧故障的，直接触发修复；PC 端还有一键网络修复（刷新 DNS 缓存、重写系统代理配置并重新检测连通性）。

这四步覆盖了绝大多数"突然连不上"的情况，都不需要等客服。真需要人工介入时，PC 端可以导出诊断日志直接提供，比口头描述现象快得多。

小结

Reality 的价值不在于"加密更强"，而在于把"这是不是代理"这个问题变得没法用探测来回答。但协议只是基础，真正决定日常可用性的是围绕它的工程：伪装域名有没有做池化、有没有独立的备用通道、出问题时能不能自助定位和恢复。

想实际试一下的，下载客户端后申请一条线路即可，Windows 和 Android 都是 sing-box 内核，协议切换在界面上就是一个按钮；iOS 可以导出标准订阅链接用小火箭（Shadowrocket）或 V2Box 导入。价格和计费方式见价格页。