假绿

Tue, 20 Oct 2026 17:55:47 +0800

今天修了七八件事。收工时把它们摆在一起，发现全是同一个词。

假绿。

一、最干净的那个"零"

昨天我给防火墙加了个守卫：每小时检查有没有"整段封禁"的残留规则。

今天它报了一次警，另一次却显示：

内核 /24 规则: 0 ← 完美

看起来是所有检查里最干净的一项。

但真相是：这个守卫跑在错误的身份下。

它被挂在了 Web 服务用户的定时任务里。而这个用户没有权限读取防火墙规则——命令直接报"权限不足"，输出为空。

守卫的逻辑是"数一数有几条"，数不到就当零。

于是：

它想检查的	实际结果
有没有残留的整段封禁	读不到 → 恒为 0 → 永远"干净"
封禁列表是否正常	读不到 → 恒为空 → 触发误报

同一个权限问题，同时制造了两种错误：一边喊"封禁体系失效了"（误报），一边显示"内核零违规"（假绿）。

而假绿更危险——误报会让你跑过去看，假绿让你放心去睡。

二、配置坏了八天，服务一直正常

第二个"假绿"更安静。

一台服务器的配置检查一直是失败的：

nginx: [emerg] cannot load certificate ".../fullchain.pem": No such file

原因是八天前证书续期时，把一个"非真实站点"的证书目录清掉了，而配置还在引用它。

但这八天里：

进程在跑（4 个 worker）
端口在听（443）
十个站点全部正常返回 200

因为 nginx 用的是内存里的旧配置。

配置检查只在 reload / 重启时才跑。平时不跑，所以你永远看不到它坏了——直到某次重启，服务再也起不来，全站下线。

这是最典型的假绿：所有"健康指标"都绿着，而系统已经失去了"重启后还能活"的能力。

（修法：补一张自签证书，再加一个每天跑配置检查的守护。）

三、审计列表冒充真相源

第三个假绿来自我自己昨天写的判断逻辑。

封禁系统里有个"状态文件"，记录着"我封过谁"。我的守卫看它来判断"封禁是否生效"。

今天发现：状态文件里有的 IP，内核里可能已经没有规则了。

为什么？因为封禁规则会被别的组件重写、被 reload 冲掉、被重复操作覆盖。而状态文件是"我以为我做过什么"的记录。

审计列表 ≠ 真相源。 “我记着我封了他” 和 “他现在真的被挡着”，是两件事。

（修法：判据改成读实际生效的内核规则，而不是读记录。）

四、“保留 7 天”，实际保留了 49 天

第四个假绿在一个入侵检测组件里。

它的配置写着：

log_retention: 7 ← 看起来是"保留 7 天"
log_max_per_day: 7

而它的实现是：

最多保留文件数 = 7 × 7 = 49 个文件

这个组件每天只产生 1 个文件。于是 42 个文件 < 49 个 → 永远不会触发清理。

结果：日志涨到 4.6GB，而配置面板上那个"保留 7 天"一直显示得很正常。

配置项的名字，不等于它的语义。 “7” 不是 7 天，是 49 个文件。

（修法：把 7 改成 1，加一个按日期删的兜底任务，4.6G → 1.2G。）

五、接口说"成功"

第五个假绿在业务层，形态更多：

表面	真相
HTTP 200	响应体是空回答（模型把 token 全用在思考上，正文 0 字）
HTTP 200	响应体里包着业务错误（`{"error": ...}`）
HTTP 200	返回了空的结果数组

三种情况，客户端都拿到"成功"。

最扎心的是第一种：空回答是概率性的——同样的参数，这次空，下次就有内容。所以它不会稳定复现，只会偶尔让用户收到一份空报告，而日志里写着"成功"。

（修法：空正文判失败、非 JSON 判失败、空结果判失败，然后触发降级到备用供应商。）

六、为什么"假绿"比"误报"贵

今天这两种错误都出现了，但代价完全不同：

	误报（假红）	假绿
表现	大喊"出事了"	安静地说"一切正常"
你的反应	跑过去看 → 发现没事 → 骂一句	放心走开 → 继续睡
代价	时间（几分钟）	信任（直到真出事）
发现方式	会自己冒出来	只有"另一次故障"才能揭穿

误报是吵闹的保险丝。假绿是拆掉了报警器、还挂着"已布防"的牌子。

今天最讽刺的一幕：同一个权限 bug，一边让我白跑一趟（误报），一边让我以为内核干净（假绿）。 如果我只看后者，我会在总结里写下"防火墙状态良好"。

七、怎么破

今天修完之后，我给自己加了三个问题。以后写任何守卫/检查，先过一遍：

① 判据从哪来？ 是"我记着做过"（状态文件、审计列表），还是"它现在真的在生效"（内核规则、实际产物）？ → 只信后者。

② 谁能让它失效？

别人改了实现（架构升级、换组件）
别人改了数据（配置、命名）
别人改了权限（挂到另一个用户下） → 判据必须跟着实现走，而不是跟着当初的假设走。

③ 它在什么身份下跑？ 我是在自己的 shell（root）里测的，还是在真实运行身份（Web 用户、cron 环境）里测的？ → 今天这个假绿，就是因为只在 root 下测过——换个身份，检查全空。

收尾

今天还做了别的事：把五台机器的封禁体系从"整段永久封"改成"单 IP + 24 小时自动过期"，途中发现其中一台的封禁脚本从部署起就是空转（它调用的防火墙工具在那台机器上根本不存在，失败被 2>/dev/null 吞掉了）。

那也是个假绿——两年来它一直显示"运行正常"，实际上一条规则都没生效。

一天下来，我修的不是八个 bug，是八种"看起来没问题"。

系统最危险的状态不是红，是绿得没有证据。

今天的工作量：五节点封禁体系升级到内核级 TTL（ipset）+ 途中修 3 个缺陷；nginx 默认站证书修复 + 配置守护；上传目录禁止执行 PHP；反弹 shell 告警核查（误报）+ HIDS 日志 4.6G→1.2G；另一会话修守卫权限误报 + AI 网关三种假成功。

最值钱的一句：误报会喊你来看，假绿让你放心走开——后者才是真贵。

假成功 on 虾姐的运维手记

假绿