先说明身份：我是 ZibVPN 项目方，这是一篇带产品介绍的推广帖。前半部分是我们做抗封锁时的一些数据和判断，不想看产品的可以只看前半部分。
我们的客户端同时接入了 VLESS + Reality 、ShadowTLS v3 、Hysteria2 和 AnyTLS 四种协议。前阵子团队整理了客户端上报的探测数据，也复盘了几个走过的弯路。这里分享出来，也想听听大家的看法。
一、近 90 天的探测数据
下面是截至 8 月初的近 90 天，客户端对各协议发起连接探测的次数和成功率：
| 协议 | 探测次数 | 成功率 |
|---|---|---|
| VLESS + Reality | 约 179 万 | 97.8% |
| ShadowTLS v3 | 约 179 万 | 99.4% |
| AnyTLS | 约 168 万 | 99.3% |
| Hysteria2 | 约 166 万 | 99.6% |
需要先说明几点，免得误读：
- 这是客户端探测的成功率，不等于用户的实际体验，也不代表这些协议在你的网络里一定可用。
- 数据来自我们自己的用户和节点，样本有偏差。
- Reality 成功率最低，并不说明它最差。它承担的场景和握手方式不同，我们也没有做过严格的对照实验。
我们自己的一个教训是：客户端上报的“当前活跃协议”字段，不能用来判断哪个协议在承载流量。我们最初就是这样误读的，后来对照流量统计才发现，实际承载最多流量的并不是它显示的那个协议。
二、为什么只靠 Reality 不够
今年 4 月，我们只用 Reality 的时候，用户反馈明显变多，表现是握手能过，但业务流量被干扰、长连接抖动。
我们当时的第一反应是 Reality 被识破了。后来看遥测，更像是行为层面的检测变强了，而不是 TLS 指纹被破解：
- 检测面一：静态指纹和主动探测。Reality 在这里很强，探测者会被转发到真实网站。
- 检测面二：流量行为和模式，比如对冷门 IP 持续灌大流量、包长和时序的特征。单一协议在这里更容易暴露。
- IP 轴：整段 IP 被封。这种情况下换协议没有用，同一个 IP 上的几个协议会一起失效，只能换 IP 或走别的线路。
加入 Hysteria2 （走 UDP ）和 AnyTLS （ padding 打乱包长和时序）之后，情况有所改善。我们现在的理解是，这是多样性容错，不是更强的隐身。多种协议只是让检测方面对多种流量形态，并不保证哪一种一定不被识别。
这是我们根据遥测和排查得出的判断，不一定对，欢迎指正。
三、为什么撤掉了 NaiveProxy
我们一度做了 NaiveProxy 作为“绝境兜底”：四个协议都被干扰时由它顶上。服务端、记账、灰度都做完了，最后还是撤掉了。原因不是没人用，而是下面这几点：
- sing-box 的 naive inbound 官方文档只有 network 、users 、quic_congestion_control 、tls 四个字段，没有 probe_resistance ，也没有任何兜底选项。不是我们没配好，是实现里就没有。
- 实测一个更严重的问题：握手时协商了
http/1.1，之后发送普通 GET 请求，服务端一个字节都不回就断开。真实的 HTTPS 服务器不会这样。探测方只要一个包、一次连接就能确定判断，不需要猜口令，也没有误判。 - 定位上有矛盾：它是“主动探测”场景下的兜底，但 Reality 和 ShadowTLS v3 的抗主动探测是设计层面的。在 naive 唯一该起作用的场景里，它反而会比它要救的协议先失效。
有一点我们要特别提醒自己：不能用“naive 一直没被用上”当作撤除理由。备份没用上本来就是正常的。撤除的理由只有上面第三条。
撤除时只改了代码，历史数据全部保留。将来如果要重做，更合理的办法是给自编译的 sing-box 打补丁，让它对非 CONNECT 请求转发给真实网站。
四、产品现状
ZibVPN 目前支持 Windows 、macOS 、iOS 和 Android ，也有 Linux 下载页。登录后选择节点即可连接，不需要自己导入订阅，也不需要自己选协议。
新注册账号可以免费试用，建议在自己的宽带和手机网络下各测一次。
不保证任何网络环境下一直可用，这一点我们不会改口。连不上、速度不理想、客户端不好用，都欢迎直接说。
想听听大家的看法
- 如果你自己维护过多协议节点，你更倾向于用“多协议冗余”，还是“少量协议 + 经常换 IP”？
- 对于主动探测的防护，你觉得有哪些我们没考虑到的检测方式？
- 如果客户端能展示当前协议和失败原因，你希望看到多详细的信息？
团队会尽量逐条回复。
Select Language