10·26 大面积节点「坠机」：IPv4 TCP 被封、UDP 还活着，ZibVPN 如何用 IPv6 自动切换恢复

2026 年 10 月 26 日下午到傍晚，很多人几乎在同一时间发现自己的节点「全红了」：自建的 VPS 连不上、 机场部分节点超时、Claude 和 ChatGPT 突然报错。技术社区里大量用户反馈，搬瓦工、DMIT、RackNerd、 AWS、甲骨文等热门服务商的服务器都受到影响，不少用了好几年都没出过问题的老 IP 也没能幸免。

这次的现象很统一：服务器能 ping 通，但所有 TCP 端口都连不上，UDP 却完全正常。于是基于 TCP 的 VLESS+Reality、Trojan、VMess 等协议大面积失效，而基于 UDP 的 Hysteria2 还能用。

ZibVPN 的部分节点同样在这次封锁范围内。这篇文章说明这次封锁的特征、我们如何发现和确认问题， 以及我们做了哪些事让用户尽量不受影响：客户端自动切换到 Hysteria2、更换被封的 IP，以及给节点加上 IPv6 备用地址，让客户端在 IPv4 被封时自动改走 IPv6。

这不是个别现象

如果你在 10 月 26 日之后突然连不上自己的节点，大概率不是你的配置出了问题。从技术社区的大量反馈和 我们自己的数据来看，这次封锁有几个共同特征：

• 按 IP 封，不是按端口或协议封。有用户测试了 80、443、SSH 端口和随机高位端口，结果都 一样连不上；抓包显示服务器收到了连接请求并发出了回应，但回应没能回到国内。
• 只封 TCP。ping（ICMP）和 UDP 都正常，所以 Hysteria2 这类基于 UDP 的协议还活着。
• 热门 VPS 的 IP 段受影响最集中。很多人判断是热门机房的 IP 段被成片阻断，冷门服务商 存活率更高；一些很久没用过的机器也一起挂了，说明和流量特征关系不大。
• IPv6 基本不受影响。不少用户换成服务器的 IPv6 地址后恢复了连接。
• 因运营商而异。同一台服务器，有人连不上，有人正常；不少反馈认为移动网络受影响更明显。

这些特征和我们的监控数据、实测结果完全一致。

ZibVPN 用户看到的现象

• 部分节点测速显示超时，或排到列表最后；
• 锁定 VLESS+Reality、ShadowTLS 或 AnyTLS 协议时，连不上这些节点；
• 「自动」模式下大多仍能连上，因为客户端会自动改用 Hysteria2，很多用户甚至没有察觉；
• 同一个节点，有的用户能用，有的用户不能用，和运营商、地区有关。

和自建用户相比，最大的区别在于：自建用户需要自己发现问题、自己去改协议或换 IP；而 ZibVPN 客户端本来就 同时准备了 TCP 和 UDP 两类协议，TCP 被封后会自动切到 Hysteria2，不需要用户动手。

时间线

• 10 月 26 日约 17:00：监控显示，全网 TCP 协议（Reality、ShadowTLS、AnyTLS）的连接失败率 从平时的 0.5% 左右跳到 5% 以上，每小时的 TCP 连接尝试量骤降到原来的三分之一左右。同一时段，技术社区 开始出现大量「节点全挂」的反馈。
• 10 月 27 日上午：确认问题不在我们的服务器本身：服务器在线、用户仍有流量（大多已自动切到 Hysteria2），日志里也没有异常。
• 10 月 27 日中午：在国内家宽环境实测，锁定被影响的节点：能 ping 通，但 443、8443、9443 等 TCP 端口全部连不上；同一台服务器的 UDP（Hysteria2）正常。
• 10 月 27 日下午至夜间：利用部分服务器已有的备用 IP 立即切换；其余服务器联系服务商更换 IP。
• 10 月 28 日：复测确认更换 IP 的节点恢复；验证 IPv6 方案，完成服务端与客户端改造， 为节点加上 IPv6 备用地址，并发布 ZibVPN 1.6.12。

我们是怎么排查的

第一步：这不是服务器故障

最先排除的是服务器问题。所有受影响的服务器都在线，管理后台显示正常，仍然有用户在用。但这些用户几乎都是 通过 Hysteria2 连接的：客户端发现 TCP 协议连不上，就自动切到了 UDP 的 Hysteria2。

这也解释了为什么不少用户「感觉没什么问题」：在「自动」模式下，客户端已经替他们完成了切换。真正受影响的 是锁定了 TCP 协议的用户，以及不会自动回退的老版本客户端。

第二步：用数据圈出范围

客户端会匿名上报各节点、各协议的连接成功率。按节点拆开来看，规律非常清楚：一批节点在前一天还有 99% 以上 的 TCP 成功率，从 26 日傍晚开始突然变成 0%；同一批节点的 Hysteria2 成功率却一直保持在 97% 以上。

还有一类节点更隐蔽：它们之前流量不小，现在却几乎没有人再用 TCP 去连。原因是客户端连续失败后会暂时拉黑 这条线路，所以「没有数据」本身就说明连不上。

第三步：在国内网络实测

数据只能告诉我们「哪些节点有问题」，真正确认原因还要靠实测。我们在国内家庭宽带上，断开 VPN 后逐台测试了 所有节点：

• ping 全部正常，说明服务器可达；
• 被影响的节点，443、8443、9443 等所有 TCP 端口都连不上；
• 换成手机热点（另一家运营商）测，部分节点又能连上。

结论是：被封锁的是这些服务器 IPv4 地址上的 TCP 连接，而且封锁程度因运营商和地区而异。第一次实测，约一半的节点在测试网络下连不上；和全网数据交叉核对后，确认其中一部分是大范围受影响，其余只是 个别运营商线路的问题。

怎么解决：换 IP 只能救急，IPv6 才是长期方案

救急：更换被封的 IP

最直接的办法是换 IP。我们先给几台本来就配有备用 IP 的服务器换上新地址，当天就恢复了；其余服务器联系服务商 更换 IP，一夜之间又恢复了十几个节点。第二天复测，连不上的节点减少了约三分之一，剩下的多数只是个别运营商的问题。

但换 IP 有两个明显的问题：一是新 IP 迟早也可能被封，变成「猫鼠游戏」；二是每次更换都依赖服务商响应， 有的要几个小时，有的要几天。

要不要等它自动解封？

社区里有不少人选择「先不换 IP，等几天看会不会自动解封」。这类封锁确实有可能是阶段性的，但什么时候解封、 会不会解封都无法预期。对服务商来说，不能让用户干等，所以我们没有把被封的 IPv4 地址删掉：如果日后解封， 客户端会自动重新用上；同时立即准备不依赖这些 IPv4 地址的替代路线。

发现：同一台服务器的 IPv6 完全正常

排查中我们注意到，很多服务器除了 IPv4，还配有 IPv6 地址，这和社区里「换 IPv6 就能用」的反馈一致。我们在 中国移动的 IPv6 网络下做了对照测试：

5 台 IPv4 已被封锁的服务器，IPv6 全部可以正常连接。随后我们把所有具备 IPv6 的节点都测了一遍，几乎全部的 IPv6 都完全正常。

这背后的原因不难理解：IPv6 地址数量巨大，一台服务器可以有成千上万个可用地址，封锁和更换的成本都和 IPv4 完全不同；目前国内对 IPv6 的封锁也远没有 IPv4 那么密集。而手机网络基本都已支持 IPv6，越来越多的家庭宽带 也默认开启。

方案：一个节点，两条路，自动选择

最简单的做法，是把每个节点的 IPv6 地址单独做成一个新节点放进列表。但这样节点列表会变得又长又乱，用户也 不知道该选哪个。

我们最终选择的方式是：同一个节点同时准备 IPv4 和 IPv6 两个地址，由客户端自动选择，用户看到的仍然是一个节点。

• 节点列表不变，「日本 · 东京」还是一个「日本 · 东京」；
• 客户端同时准备 IPv4 和 IPv6 两条路，哪条能连、哪条更快就用哪条；
• IPv4 被封时，自动改走 IPv6，四种协议（VLESS+Reality、ShadowTLS v3、AnyTLS、Hysteria2）全部可用；
• 当前网络没有 IPv6 时，客户端直接只用 IPv4，不会多等一秒；
• 锁定某个协议的用户同样受益：客户端只会在这个协议的 IPv4 和 IPv6 之间切换，不会把你切到别的协议。

上线测试中，几台 IPv4 已被封锁的欧洲、日本节点，在新版客户端上都通过 IPv6 重新用上了 VLESS+Reality， 节点列表和使用方式都没有任何变化。

同时做的几件事

• 给所有具备 IPv6 的服务器重新检查并补齐了 IPv6 的安全配置，只开放提供服务所需的端口；
• 新增了按 IPv4 / IPv6 区分的连接统计，以后能更早发现「某个地址被封」的情况；
• 改进了后台流程：更新节点的 IPv6 地址时不需要重启节点，在线用户不会掉线。

这次事件影响用户数据或账号安全吗？

不影响。这是一次网络可达性问题：部分服务器地址在国内被封锁了 TCP 连接，服务器本身、账号数据、支付信息 以及 VPN 的加密都没有受到影响。

你需要做什么？

1. 升级到 ZibVPN 1.6.12 或更新版本。IPv4 / IPv6 自动切换是 1.6.12 起才有的能力，请从官方下载页面获取最新版本。
2. 协议建议保持「自动」。「自动」模式会在 TCP 受阻时自动改走 Hysteria2，也会在 IPv4 被封时 改走 IPv6。只有在明确知道自己需要时，才手动锁定协议。
3. 遇到个别节点连不上，先换一个节点。这次的封锁程度因运营商和地区而异，同一时间不同网络下的 表现可能完全不同。
4. 仍然有问题，请通过 App 内的「意见反馈」告诉我们节点名称、时间、网络类型（Wi-Fi 还是手机流量、哪家运营商）。

常见问题

为什么能 ping 通服务器，VPN 却连不上？

ping 用的是 ICMP，VPN 用的是 TCP 或 UDP。这次的封锁只针对 TCP 连接，所以会出现「ping 正常、TCP 全部超时」 的现象。这时 UDP 协议（Hysteria2）往往仍然可以使用。

我的网络支持 IPv6 吗？

手机流量（中国移动、联通、电信）基本都已支持 IPv6；家庭宽带要看运营商和路由器设置，很多已默认开启。可以在 关闭 VPN 后访问任意 IPv6 检测网站查看。即使没有 IPv6 也不影响使用：客户端会自动只用 IPv4，并在 TCP 受阻时 改用 Hysteria2。

IPv6 会更慢或更耗流量吗？

不会额外消耗流量，流量只经过当前选中的那一条路。速度取决于具体线路，客户端会优先选更快的那条。

Reality 是不是被识别了？

从这次的情况看不是。被封的是服务器 IP 的整个 TCP，不管上面跑的是 Reality、Trojan、VMess 还是 SSH，都一样 连不上；同一台服务器的 UDP 和 IPv6 却正常。换协议能解决问题，是因为换到了 UDP，而不是因为 Reality 本身被破解。

我是自建用户，有什么临时办法？

社区里验证有效的临时办法主要有三种：改用基于 UDP 的 Hysteria2；如果服务器有 IPv6、你的网络也支持，改用 IPv6 地址连接；或者更换服务器 IP（新 IP 也可能再被封）。要注意的是，频繁更换出口节点，可能让 AI 等对 IP 敏感的服务 触发风控。如果不想每次都自己处理，选择支持多协议、多地址自动切换的服务会省心很多。

为什么不直接把所有节点都换成新 IP？

我们也在换，但这只能救急：新 IP 同样可能被封，更换也依赖服务商的响应速度。IPv6 备用地址加上客户端自动切换， 让单个地址被封时用户几乎感觉不到，这才是更长期的办法。

老版本客户端还能用吗？

可以。老版本不认识新增的 IPv6 地址，会和以前一样只使用 IPv4，在「自动」模式下仍可通过 Hysteria2 连接。 建议尽快升级，以获得 IPv6 自动切换能力。

写在最后

10·26 这次封锁影响了大量自建用户和服务商，也再一次说明：单一协议、单一地址的方案，在大规模封锁面前几乎 没有余地。网络环境在持续变化，任何服务商都无法承诺「永远不会被封」。我们能做的，是让一次封锁尽量不影响你的 使用：多协议覆盖 TCP 和 UDP，多地址覆盖 IPv4 和 IPv6，并由客户端自动完成切换，而不是让用户自己猜该换哪个 节点、哪个协议。关于四种协议各自的特点，可以阅读《2026 VPN 协议怎么选》。