内容摘要：上周三凌晨两点，运维群里弹出一条告警：某台边缘节点上的 Nginx 进程 CPU 占用飙到 780%。我爬起来连上机器，发现是 upstream 健康检查模块在特定并发下会反复重建连接池，把 work

上周三凌晨两点，漏洞运维群里弹出一条告警：某台边缘节点上的修复 Nginx 进程 CPU 占用飙到 780%。我爬起来连上机器，情况发现是说明 upstream 健康检查模块在特定并发下会反复重建连接池，把 worker 进程拖死了。漏洞这其实是修复个老漏洞，CVE 编号我记不清了，情况补丁三个月前就出了，说明但生产环境一直没打——因为那台节点跑的漏洞是定制内核，标准补丁包直接装会崩。修复

漏洞修复这件事，情况最麻烦的说明从来不是“修”，而是漏洞“怎么修才不出新问题”。我见过太多团队把补丁当创可贴，修复一出事就紧急上线，情况结果旧洞堵了，新洞又开。去年有个做支付的朋友，他们修一个反序列化漏洞，直接升级了 Fastjson 版本，结果下游某个老服务依赖的字段名变了，线上订单丢了十几分钟。后来他们定了个规矩：任何安全补丁必须先在预发环境跑满 72 小时，还得带上流量回放。

说回我们那台 Nginx。当时有两个选择：一是硬着头皮编译一个带补丁的定制内核，风险是可能引入未知的 ABI 不兼容；二是绕开健康检查模块，用外部脚本做探活。我选了后者。写了个 Python 小脚本，每 5 秒 curl 一次后端，失败三次就调 Nginx 的 API 摘节点。跑了一周，CPU 稳在 12% 左右。那个 CVE 补丁到现在也没打——不是不想打，是评估下来收益太低，成本太高。

这引出一个挺现实的问题：不是所有漏洞都值得修。CVSS 评分 9.8 的洞，如果暴露面只有内网、且访问需要双向证书，实际风险可能比一个 5.0 的洞还低。我习惯用“修复性价比”来排序：补丁成熟度、业务中断窗口、回滚难度、攻击链可达性，四个维度打分。分数低的，就挂个 WAF 规则先挡着，或者加个监控告警，等下次大版本迭代一起处理。

但有些洞不能拖。比如 Log4j2 那次，我们凌晨四点收到情报，六点前就把所有 JVM 参数加上了 -Dlog4j2.formatMsgNoLookups=true。这个动作不需要重启，改完配置滚动 reload 就行。后来官方补丁出来，我们又花了两天做全量升级。那两天里，安全团队每小时扫一次外网端口，确认没有新的利用尝试。这种时候，速度和覆盖面比优雅更重要。

修复过程中还有个坑：补丁本身可能带毒。前年有个开源库的维护者账号被盗，攻击者在补丁里塞了后门。我们当时正好在用那个库，幸好有个习惯——所有第三方依赖升级前，先 diff 源码，再看 commit 签名。那次发现补丁里多了一个 base64 解码的 eval 调用，直接拉黑了那个版本。所以现在我的流程里，补丁验证和漏洞验证一样重要。

最后说个观察。很多团队把漏洞修复当成安全团队的事，开发只管合代码。这不对。真正有效的修复，得让写业务的人参与进来——他们知道哪个接口能降级、哪个字段能临时写死、哪个服务可以短暂下线。我见过一个高手，修一个 SSRF 漏洞时，没改一行框架代码，只是在网关层加了一条正则，把内网 IP 段全部 302 到蜜罐。攻击者打了三天，全打在空处。这种修法，安全团队想不出来。

漏洞修复没有银弹。每个补丁背后都是权衡：修不修、什么时候修、修到什么程度。我的原则是——能绕就绕，能挡就挡，非修不可的时候，先想好怎么回滚。毕竟，线上跑着的业务，比一个 CVE 编号重要得多。