从“设备数超限”误报到全面恢复：ZibVPN 8·7 登录故障复盘

2026 年 8 月 7 日晚至 8 日，大部分 ZibVPN 用户遇到客户端无法登录，并被错误提示 “设备数超限”。实际原因并非账号或设备限制，而是客户端使用的一组 Cloudflare 优选入口 全部返回 HTTP 403（error 1034），同时旧版客户端没有正确识别和切换故障线路。 本文公开说明事故经过、修复结果，以及我们为防止类似问题再次发生所完成的系统性改进。

先向受到影响的用户道歉

2026 年 8 月 7 日约 20:00 起，大部分用户在打开 ZibVPN 客户端时无法完成登录， 并看到“设备数超限”的错误提示。

这个提示是不准确的。大多数受影响账号并没有超过设备数量限制，删除设备、重新安装客户端 或反复登录也无法真正解决问题。错误信息不仅让用户感到困惑，也让我们的早期排查走了弯路。

对此，我们向所有受到影响的用户郑重道歉。

稳定连接是 ZibVPN 最基本的责任。发生故障后，用户不应该靠猜测来判断问题，更不应该在错误 提示下反复删除设备、重装应用。我们有责任把问题讲清楚，也有责任说明：除了恢复服务， 我们还做了哪些改变，确保下一次类似风险不会以同样方式演变成大面积故障。

故障与恢复时间线

• 8 月 7 日约 20:00–20:10：客户端上报量出现明显下降，大部分用户开始无法登录；
• 8 月 8 日凌晨至上午：团队持续排查账号限额、服务端、网络、客户端缓存及不同入口；
• 8 月 8 日约 11:00：在真实客户端上确认 Cloudflare 403 / error 1034， 撤下故障入口并完成第一阶段恢复；故障设备实测重新登录成功；
• 8 月 8 日 18:46：完成新一组跨网段健康入口部署，恢复多通道之间的独立故障隔离；
• 随后：Windows、macOS、iOS、Android 客户端陆续完成错误处理、 自动切换与配置恢复能力修复；
• 截至本文发布：Windows、Android 1.4.9 已提供下载； macOS、iOS 1.4.9 正在完成发布。

第一阶段恢复解决了服务端继续下发故障入口的问题，但已经缓存旧地址的客户端不能可靠自行恢复。 因此，客户端升级是本次完整修复不可缺少的一部分。

到底发生了什么？

ZibVPN 客户端在登录前，会通过多条入口连接控制服务。这些入口包括 Cloudflare Anycast、 经过优化的 Cloudflare IP，以及独立备用通道。它们的目标是让不同地区、不同运营商和不同 网络环境下的用户，都能找到一条可用路径。

本次事故中，客户端当时使用的 4 个 Cloudflare 优选 IP 全部返回：

这类错误的特殊之处在于：

• TCP 连接可以建立；
• TLS 握手和证书校验也可以通过；
• 服务器会快速返回 HTTP 响应；
• 但该入口并不为 ZibVPN 的域名提供实际服务，因此业务请求被拒绝。

换句话说，这些入口“看起来连得上”，但实际上无法完成任何登录请求。

问题随后被旧版客户端的两个缺陷进一步放大：

• 客户端把这类非业务 403 错误映射成了“设备数超限”；
• 客户端把“收到 HTTP 响应”误认为连接成功，没有自动切换到其他健康通道。

两个问题叠加后，客户端进入了一个死循环：它连接到了一个会拒绝请求的入口，却认为该入口 是健康的，因此不会尝试备用线路，也无法拉取新的入口配置。

为什么一开始没有立即发现？

事故初期，我们看到源站访问日志中没有对应登录请求，同时浏览器访问 API 域名又是正常的。 这个组合一度让排查方向偏向客户端本地网络或设备环境。

浏览器与 App 的路径也并不相同：浏览器通过系统 DNS 访问当时健康的地址，而旧版 App 可能仍在使用本地缓存中的故障优选 IP。因此，“浏览器能访问”并不能证明 App 实际使用的 路径同样健康。

最终的突破来自客户端与服务端的联合排查：我们在真实客户端日志中看到了明确的 HTTP 403， 而同一时刻源站没有对应请求。随后逐一验证 4 个优选 IP，确认它们全部稳定返回 1034， 根因由此锁定。

我们如何恢复服务？

第一阶段：立即止血

我们首先将故障优选 IP 全部撤下，替换为已经确认能够返回正常业务响应的健康入口， 使客户端重新获得登录和配置更新能力。

止血阶段的唯一目标是尽快恢复可用性，因此我们优先选择经过真实 HTTP 200 验证的地址， 而不是继续追求理论上的最低延迟。

第二阶段：恢复多通道独立性

紧急恢复后，我们重新筛选并部署了 4 个来自不同网络段的 Cloudflare 入口。每个入口都经过 真实业务路径验证，并刻意避开系统 DNS 当前使用的地址，避免“主通道”和“备用通道” 表面上有两条、实际上共享同一故障源。

新的入口分布在多个独立网段。即使其中一个地址未来失效，客户端也可以切换到其他入口， 而不是再次出现整组同时失效。

第三阶段：客户端修复

Windows、macOS、iOS 和 Android 客户端随后完成修复：

• 不再把网络层或 CDN 403 错误显示成“设备数超限”；
• 非业务 HTTP 4xx/5xx 会被视为通道失败；
• 当前通道被拒绝时，自动尝试下一条健康线路；
• 改进首次启动、缓存配置和远程配置获取的恢复能力。

这不是简单的“换了几个 IP”

如果只更换 4 个地址，问题只是暂时消失，并没有真正解决。

因此，本次事故后，我们围绕“选址、客户端、监控、回退”四个层面完成了系统性整改。

1. 优选 IP 上线前增加三道硬门槛

• 真实业务验证：使用 ZibVPN 域名和真实 HTTPS 路径验证，必须返回 HTTP 200；
• 故障域隔离：避免与系统 DNS 的 Anycast 地址重叠，确保备用线路真正独立；
• 网络分散：多个入口分布在不同网段，避免一次策略变化影响全部地址。

2. 从“连接层健康”升级为“应用层健康”

旧逻辑主要观察 TCP、TLS 和响应速度。新逻辑进一步检查真实 HTTP 状态和业务响应。 以后即使某个入口握手正常、延迟很低，只要它无法提供业务服务，就会被降级并触发自动切换。

3. 新增专门的 HTTP 失败遥测

我们新增了独立的 HTTP 失败监控类别，用来区分：

• TCP 无法连接；
• TLS 握手失败；
• 连接成功但应用层拒绝服务；
• 正常的账号或业务错误。

这使我们能够更快判断问题究竟来自网络、CDN 入口，还是正常业务逻辑， 避免不同故障被混入同一个错误指标。

4. 增加“上报量骤降”告警

本次事故暴露了一个很容易被忽略的监控悖论：故障最严重的客户端，可能连故障遥测本身都 无法上报。如果只看成功率，看板甚至可能仍然是绿色的，因为能够上报的恰好都是健康客户端。

为此，我们增加了按历史同时段对比的上报量骤降告警。当大量客户端突然沉默时， 即使没有任何错误上报，系统也会主动预警。

5. 为远程配置建立自动校验

服务端下发的通道配置现在会按照客户端真实的解析和运行规则自动检查，包括：

• 地址格式是否合法；
• 通道字段是否完整；
• 传输类型是否受当前客户端支持；
• 配置数量是否超过客户端实际消费能力；
• 备用线路是否真的可以返回业务响应。

过去某些“服务端看起来配置成功、客户端却静默忽略”的问题，现在会在上线前直接被阻止。

6. 回退路径也必须在平时接受验证

这次复盘中，我们还发现一组故障地址曾残留在服务端的默认回退配置中。虽然正常情况下不会使用， 但如果主配置读取失败，它可能在最糟糕的时刻重新启用旧地址。

我们已经清除这一隐患，并确立了新的工程原则：

这次事故涉及用户数据或账号安全吗？

我们的排查未发现本次事件涉及用户账号、支付信息或 VPN 加密数据泄露的迹象。

这是一次控制服务入口的可用性事故：大部分客户端无法通过故障入口 完成登录或获取配置，并收到错误提示。已确认的问题集中在连接路径、入口配置和错误处理， 不是账号数据库被入侵，也不是 VPN 加密机制失效。

我们从这次事故中学到了什么？

第一，错误提示不是文案问题，而是可靠性问题

“设备数超限”这句错误提示，把用户和工程团队都带向了错误方向。准确的错误分类不仅影响体验， 也直接影响故障定位速度。

第二，监控不能只看还能发出声音的人

真正受影响最严重的用户，往往最难出现在日志和遥测里。今后的告警会同时观察失败率、 真实 HTTP 状态和整体上报量，而不是只依赖单一成功率。

第三，备用线路必须拥有独立故障域

线路数量多，不代表真正冗余。如果多条线路共享同一地址来源或同一种失效条件， 它们仍可能同时失效。我们会继续保持 Cloudflare、系统 DNS 和独立备用通道之间的故障隔离。

第四，透明复盘比掩盖故障更能建立信任

我们不会把这次问题简单描述为“网络波动”，也不会把责任全部归结为第三方。

Cloudflare 返回 1034 是直接表现，但事故能够影响用户，是因为我们的优选 IP 准入缺少真实业务 校验，旧版客户端又没有正确处理这类 HTTP 错误。配置和客户端两侧都有可以改进的地方， 我们已经完成相应整改。

我们能向用户承诺什么？

任何在线服务都无法诚实地承诺“永远不会故障”。我们能承诺的是：

• 发生问题时，不回避、不含糊，不用“网络波动”掩盖真实原因；
• 优先恢复用户使用，再完成根因分析和长期整改；
• 把一次事故变成自动化检查、监控和故障切换能力，而不是只修当前现象；
• 持续维护 Windows、macOS、iOS 和 Android 四端客户端；
• 在关键故障后公开说明发生了什么、修复了什么、还有什么限制。

本次事故让我们付出了代价，也让 ZibVPN 的控制链路比事故前更健壮：入口上线有硬门槛， 客户端能识别应用层失败，监控能够看到“沉默的故障”，回退配置也有自动校验。

这不是一句“已经修复”就结束的工作，而是一次可靠性体系的升级。

感谢每一位在故障期间耐心反馈、提供日志和协助测试的用户。你们提供的每一条信息， 都帮助我们更快锁定问题，也推动我们把 ZibVPN 做得更可靠。