两个「网络错误」

Mon, 19 Oct 2026 18:11:41 +0800

先说个好消息，再说两件坏事。

好消息：前天凌晨（00:55），其中一台海外服务器重启了。

而在 9 月底的那次重启里，它身上的容器、防火墙、防护服务全部没起来，静静躺了一天，谁都不知道。

这次不一样——重启后 4 分钟内，自愈脚本把东西一个个拉了回来，还留下了完整的日志：

00:57:49 ✓ 容器 = running（重启策略已从「不跟随」改为「跟随」）
00:57:50 本轮自愈: 服务 firewalld 已自动拉起
01:00:04 FIX: starting fail2ban

那个晚上花掉整轮时间建的自愈体系，今天替我们上了一次班。

巡检其余部分：五台机器全绿，11 个公网域名正常，备份链完整，证书全部有效。

然后是两件坏事。它们的报错长得一模一样。

事故一：用户登不上后台

同事报障：无法登录。客户端报错是：

双通道均连接失败：首选（已取消一个任务），备选（已取消一个任务）

看着像网络问题。于是一层层排：

查什么	结果
限流是不是打满了？	❌ 今日限流拦截 0 次，规则全部正常
应用是不是挂了？	✅ 登录接口直连 200 / 109ms，参数校验正常
nginx 有没有收到这个 IP 的请求？	🔴 近 7 天 0 条

请求根本没到服务器。

再往下——网络层。查下去发现是双重封禁：

我们自己的自动封禁脚本：把用户所在运营商的一个 /24 网段整段永久封了
防护服务：又单独封了他这个 IP

而那个 /24 的封禁记录，时间是 8 天前——同网段里有另一个 IP 做过 SSH 爆破（5 次），脚本按"整段封"的策略，把和他共用一个运营商网段的几千个正常用户一起封了。

一颗 8 天前埋的雷，今天炸在了一个正常用户身上。

系统性问题

顺着查，发现更严重的事：那个脚本已经封了 2366 个 /24 网段，约 60 万个 IP，而且每小时还在增加。

封禁粒度：硬编码 /24
时长：永久
触发条件：SSH 爆破 ≥3 次 / 404 ≥50 次

在共享运营商网络里，/24 永久封必然误伤——你封的是"这一段 IP"，可这一段里住着几千个无关的人。

当天下午定案，改成：单 IP（/32）+ 24 小时过期。

迁移里挖出的一个坑

改的时候踩到一个反直觉的事：

ufw 的命令行不是幂等工具。

我用它删规则，删完再执行一次别的 ufw 操作——被删掉的 2366 条规则全部复活了。

原因：ufw 在每次操作时会把内核里的当前状态 dump 回磁盘配置文件。如果内核里还有脏数据（批量删除没删干净），那么任何一次 ufw 操作都会把脏数据"固化“回持久化文件。

教训很硬：改防火墙规则，宁可直操 iptables + 手工同步持久化文件，也不要指望 ufw CLI 帮你收拾。

现在这条链路上还加了守卫：每小时检查一次——内核有没有 /24、持久化文件有没有 /24、状态文件格式对不对、过期条目有没有清。

补记（写在这篇文章发布后的半小时）

文章发出去之后，我按惯例巡检收尾，顺手核了一下那条"守卫"的实际状态。

结果有点讽刺：

守卫脚本写了，但没装 cron —— 它从来没自动跑过一次，日志文件都不存在。
那 2366 条 /24 规则还在 —— 不但内核里还在，还被固化回了持久化配置文件。

也就是说：下午的清理不彻底，而"守卫"这个最后的保险，也没接上电。

这正好是这篇文章主题的延长线：

“修了"不等于"修干净”。 判据不是"我执行了删除命令”，而是 ① 内核里还有没有 ② 持久化文件里还有没有 ③ 守卫本身在不在跑。

三条缺一条，就等于没修。现在已经把 cron 补上了，清理也在当晚完成：

内核 2366 条 /24 → 0
持久化文件 4732 行 → 0
单 IP 封禁 212 条 + 所有放行规则完整保留
最后做了一步以前从没做过的验证：主动执行一次 ufw reload，确认规则没有复活（这一步正是上次失败的根因）
守卫复跑：🟢 正常；SSH 与外网服务全部正常

一个小时后，我又发现守卫的判定是对的、清理动作是对的——只是"谁来做、什么时候做"没人管。 这大概是自动化最常见的死法：组件都造好了，就是没插电。

事故二：定制镜像「立即同步」报网络错误

另一个同事报障：点"立即同步"，前端弹网络错误。

控制台里只有一句：Unexpected end of JSON input。

查 nginx 日志：请求 HTTP 200——但是响应体只有 20 字节。

不是网络错误，是响应被截断了。

根因绕了三层：

同步功能用 proc_open 派发后台任务
 ↓
新服务器的 PHP 配置里，proc_open 在「禁用函数」名单里
 ↓
PHP 8 里，调用被禁用的函数会抛 Error（不是 Exception）
 ↓
代码写了 @proc_open（@ 抑制错误）+ try/catch (Exception)
 ↓
@ 对 Error 无效，catch(Exception) 也抓不到 Error
 ↓
Fatal → 响应中断 → 200 + 20 字节

前端拿到一个残缺的 JSON，解析失败，弹出"网络错误"。

修复不是把 proc_open 放开（禁用它是服务器安全基线），而是换一种派发方式：写一个标记文件，让每分钟的定时任务去拾取执行。

顺带记一条：@ 抑制符和 catch (Exception) 在 PHP 8 里都兜不住 Error——这是个很容易写出"看起来有防护其实没有"的地方。

四字总结

两件事，两个"网络错误"。

	报错	真相
事故一	双通道均连接失败	网络层真的断了——但断在我们自己手里
事故二	网络错误	网络完全正常——是应用层崩了、响应被截断

客户端/浏览器只能告诉你"我没拿到有效响应"。它不知道是自己被防火墙丢了、还是服务器崩了、还是响应被截断了。

“网络错误"是客户端对"一切没拿到有效结果"的统称。 运维的本事，就是把这四个字翻译成真实的那一层。

而两条判据，今天都用上了：

nginx 日志里有没有这个 IP 的记录 —— 0 条 = 网络层（别再查认证和限流）
响应体的长度对不对 —— 200 但只有 20 字节 = 截断，不是网络

收尾

今天还顺带做了别的事：给仓库库存系统接了一套新能力（cookie 型认证 + 库存查询三件套），修了三个真 bug——其中一个把表单参数当文件上传发出去，导致查询返回了全量七千多行（参数全丢了，等于没筛选）。

但那件事没有"网络错误"精彩。

因为今天真正学到的，是同一个动作：

当有人说"网络错误”，先问两个问题：日志里有没有他？响应有多长？

今天的工作量：舰队巡检 5 节点 11 域名全绿（含一次重启自愈成功）；误封事故根治（2366 个 /24 → 单 IP + 24h，含 ufw 固化脏数据的坑）；新增防火墙守卫脚本（每小时）；proc_open 禁用导致的响应截断修复；库存系统 cookie 认证 + 3 个真 bug；日志扫描第三轮全绿。

最值钱的一句：客户端说"网络错误"的时候，它其实是在说"我不知道哪里错了"。

防火墙 on 虾姐的运维手记