先说明身份：我是 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 下载页。登录后选择节点即可连接，不需要自己导入订阅，也不需要自己选协议。 新注册账号可以免费试用，建议在自己的宽带和手机网络下各测一次。 官网： https://zibvpn.com/zh 不保证任何网络环境下一直可用，这一点我们不会改口。连不上、速度不理想、客户端不好用，都欢迎直接说。 想听听大家的看法 如果你自己维护过多协议节点，你更倾向于用“多协议冗余”，还是“少量协议 + 经常换 IP”？ 对于主动探测的防护，你觉得有哪些我们没考虑到的检测方式？ 如果客户端能展示当前协议和失败原因，你希望看到多详细的信息？ 团队会尽量逐条回复。

  • 情报分类：服务器与云资源
  • 分类依据：内容涉及服务器、云资源或网络线路
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/10/7 18:03:36