讲个笑话，飞舞博主nginx日志飙了20GB

0x00 案发：开局两眼一抹黑

起初，我根本不知道是啥玩意儿把服务器的内存和磁盘吃得干干净净的。

打开监控一看，好家伙，磁盘使用率直接 100% 锁死，曲线拉出了一根漂亮的大阳线。此时的服务器已经陷入了极其诡异的状态：SSH 连上去卡得像 PPT，各种原本跑得好好的后台脚本（比如 python3.7）接连抛出 Segfault 段错误直接崩溃。

满屏的报错全都是烟雾弹！系统连个临时文件都写不进去，陷入了“报错 -> 记录日志 -> 没空间 -> 死锁”的恶性循环。当时我整个人是懵的，到底是什么内鬼在一夜之间把几十 G 的空间给吃干抹净了？

0x01 破案：20GB 的巨型日志与连环雷

好不容易挤出一点资源敲进了排查命令，顺藤摸瓜一看，真凶竟然是 Nginx 的 error.log——它硬生生把自己膨胀到了 20多GB！

你敢信？一个文本日志文件，一夜之间长了 20G。把日志末尾拉出来一看，这其实是一场由三个“致命巧合”叠加引发的终极灾难。

连环雷 1：配置文件里的“复读机”

很久之前，为了防止恶意扫描，我在 Nginx 的 cn_ip.conf 里加了中国 IP 段的黑/白名单。但由于复制粘贴失误，里面有几万条网段是完全重复的。 平时这只是个隐患，Nginx 在后台安静运行时啥事没有。但只要 Nginx 一重启，它就会对这几万条重复记录疯狂触发 [warn] duplicate network 警告。

连环雷 2：“一国两主”的 80 端口争夺战

光有警告还不足以刷出 20GB。真正的导火索在于我新装了 1Panel 面板，但旧的宝塔面板却没有彻底卸载干净。 昨晚服务器自动重启时，灾难降临了：宝塔的 Nginx 和 1Panel 的 Web 服务在同一秒苏醒，开始疯狂抢夺 80 端口。

• 1Panel 抢到了 80 端口。
• 宝塔的守护进程发现自己没抢到（报错 bind() to 0.0.0.0:80 failed），以为 Nginx 挂了，于是立刻执行重启。
• 每重启一次，Nginx 就去读一次那个含有几万条重复 IP 的配置，瞬间喷出几万条 Warning。
• 守护进程一秒钟疯狂重试无数次，Nginx 就一秒钟喷几十万条日志……

就这么死循环了一夜，20GB 的错误日志硬生生把磁盘撑爆了。

连环雷 3：惨遭 AI 背刺的 Umami

在服务器濒临崩溃、磁盘 100% 满死的危急关头，我找 AI 帮忙排查。 这哥们一顿猛如虎的分析后，给了我一行极其暴力的 Docker 清理命令。我当时也是急病乱投医，一回车——好家伙，直接把我的 Umami 统计容器连根拔起、挫骨扬灰了！

痛击我的队友，就在这一瞬间完成了闭环。

0x02 扫雷：拯救服务器

虽然经历了被 AI 瞎指挥误杀容器的惨剧，但好在底层数据没丢。为了彻底根治这个奇葩问题，我连滚带爬地执行了以下抢救：

1. 拔除复读机：用一行 awk 命令，直接把配置文件里的几万条重复 IP 去重。

   Bash

   awk '!seen[$0]++' /www/server/nginx/conf/cn_ip.conf > /www/server/nginx/conf/cn_ip_clean.conf && mv /www/server/nginx/conf/cn_ip_clean.conf /www/server/nginx/conf/cn_ip.conf

2. 扬掉日志：手起刀落，瞬间清空那 20GB 的垃圾日志，把喘不过气的系统救了回来。

   Bash

   > /www/server/nginx/logs/error.log

3. 清理前任：跑了宝塔官方的卸载脚本，彻底断绝两个面板“抢夺 80 端口”的修罗场。

4. 起死回生：万幸 Umami 的 PostgreSQL 数据库是原生装在宿主机上的，历史统计数据毫发无伤。顺着之前残留的 swapfile_umami 线索找到了配置文件，重新 docker compose up -d，完美复活。

0x03 结语

作为一名“飞舞”博主，这次的 20GB 日志惨案给我狠狠地上了一课：

1. 一山不容二虎：换运维面板一定要卸载干净！旧面板的守护进程一旦变成“僵尸”，杀伤力堪比 DDoS。
2. 不要无视配置文件里的 Warning：量变引起质变，平时看着无伤大雅的警告，在陷入死循环时就是压垮服务器的最后一根稻草。
3. 执行 AI 的 rm 操作前一定要三思：它不仅能帮你删掉垃圾日志，还能顺手把你的生产环境一起扬了 :)