漏掉的那条 IPv6 路由：一次订阅源批量超时的排查

有些故障，藏在你看不见的地方。不是源站挂了，不是网络断了，而是一条被遗忘的 IPv6 路由，让三分之二的订阅源，在同一个早晨集体沉默。

写在前面

我的在线阅读器跑在某台 VPS 上，几百个订阅源，一直安稳。直到那个早上，一个追番的源开始报错：

cURL error 28: Connection timed out after 15002 milliseconds

起初我以为只是个别源被墙了，打算随手换个镜像地址了事。可当我顺手查了一眼数据库，才发现这个"个别源"根本不个别——那天早上，有 1588 个源同时在报同样的错，另有 718 个已被系统自动禁用。而平时，每天只有一两个源会报错。

这显然不是巧合。这更像一场有规律的、沉默的故障。

问题现象

  • 追番订阅源（蜜柑计划）报 cURL error 28，15 秒连接超时
  • 数据库统计：同一天 1588 个源报错，占全部源的半数以上
  • 但并不是全军覆没——还有 640 个源成功更新了

为什么偏偏是这 1588 个？剩下的 640 个凭什么活着？这两个数字之间的分界线，就是钥匙。

排查：两条对比

排查过程由 Hermes Agent 通过 SSH 自动完成，我只负责看它递过来的证据。

第一条对比：宿主机 vs 容器。

在宿主机上直连报错的域名——HTTP 200，0.7 秒返回，源站根本没挂。可阅读器的容器里，同一个地址，走代理就超时。问题不在源站，在我的服务这一侧。

第二条对比：强制 IPv4 vs 默认。

容器里跑了两条命令：

curl -sS --max-time 8 https://mikanani.me/RSS/MyBangumi?token=***   # 默认：超时
curl -4 -sS --max-time 8 https://mikanani.me/RSS/MyBangumi?token=*** # 强制 IPv4：200

同一个地址，一个超时，一个秒开。再把代理环境变量临时去掉直连，六个站点全部 200、毫秒级。

真相浮出水面：

目标走代理·默认走代理·强制 IPv4直连
mikanani.me超时200200
south-plus.org超时302200
www.google.com超时—200
www.bilibili.com200—200

规律一目了然：带 AAAA（IPv6）记录的站点，走代理全挂；纯 IPv4 的站点一切正常。

根因：一条漏掉的路由

我的阅读器容器强制走一个 SOCKS5 代理——WireGuard 隧道接 Cloudflare WARP，用于绕开某些站点对机房 IP 段的屏蔽。当初搭建时，隧道配置里有一行：

AllowedIPs = 0.0.0.0/0

只有 IPv4。而 wgcf 生成的接口地址里其实带着 IPv6（一个 2606:4700:... 的 /128），路由却只放行了 IPv4。

问题链条是这样的：

  1. 蜜柑、谷歌、南+这些站都在 Cloudflare 前面，有 AAAA 记录
  2. 客户端解析时，IPv6 排在地址列表第一位
  3. curl 走 SOCKS5 代理时不做 Happy Eyeballs 双栈回退——它不会"IPv6 不通就试 IPv4"，而是把第一个地址（IPv6）直接交给代理
  4. 代理的隧道没有 IPv6 路由，接住这个目标后只能干等，直到 15 秒超时

容器自身没有任何 IPv6 地址（/proc/net/if_inet6 是空的），所以直连时反而没有这个问题——没有 IPv6，就直接走 IPv4 了。讽刺的是，正是为了"多一层保障"而搭的代理，成了这场故障的放大器。

修复：一条 sed

修复简单到不像话——给路由放行 IPv6：

sed -i 's|^AllowedIPs = 0\.0\.0\.0/0$|AllowedIPs = 0.0.0.0/0, ::/0|' warp-proxy.conf
systemctl restart wireproxy

重启代理，验证：

mikanani.me  => 200 (0.87s)
www.google.com => 200 (0.24s)
south-plus.org => 200 (0.62s)

全部秒开。阅读器容器一行没动——问题从头到尾都在代理这一层。

恢复：七百多个源

被自动禁用的源也一并恢复。这里有个讲究：只清错误、恢复正常调度，但不重置更新时间戳。如果一股脑把时间戳清零，718 个源会同时冲上来更新，再来一场全量风暴——那正是今早事故的诱因。

写在最后

回头看，这场故障有三个"最不像问题的地方"：

  • 源站是好的（直连 200）
  • 代理是好的（隧道握手正常，warp=on）
  • 配置是好的——只漏了 ::/0 这四个字符

排查的钥匙是那两张对比表：宿主机 vs 容器、IPv4 vs 默认。故障往往不在最显眼的地方，而在"多出来的一层"里。

感谢 wgcf、wireproxy 与 Cloudflare WARP 这些开源项目，也感谢那些把错误日志写得足够完整的站点——cURL error 28 虽然枯燥，却是我唯一的灯塔。

2026 年 8 月末。全部排查与修复由 Hermes Agent 通过 SSH 完成。

文章目录