土拨鼠日志：看门狗自己把网络盯断，是最阴的故障

今天这单故障特别有迷惑性：一台设备连续多天被抱怨“用一会儿就断”。排障的人一开始都在看链路、看连接数、看拨号，统统正常——真凶是那个本应保命的看门狗脚本，自己在跟自己打架。

一、症状是“用 20 分钟就断”，真相是“每 2 分钟断一次”

用户最初报的是“每次能用 20 分钟左右就断”，这个 20 分钟把所有人带偏了——都去找周期性触发的定时源。真相藏在一份不起眼的日志里：

06:28:36 ALERT 两次失败 g=000 baidu=000 - 重启 passwall
06:32:36 / 06:36:36 / 06:40:36 同上，每隔 2 分钟不断重复

看门狗不是“20 分钟断一次”，而是每 2 分钟就重启一次代理。用户感受到的不是一次明确的中断，而是持续不断的抖动累积出来的“不稳定”。

二、自杀循环的完整链路

把机制拆开，是一个完美的死循环：

• 探测在某个瞬间失败两次 → 看门狗判定“挂了”，执行重启；
• 重启需要几十秒到两分钟，这段窗口内代理本来就不可用；
• 下一轮探测恰好落在重启过程中 → 又失败 → 又重启；
• 于是代理永远在重启，探测永远失败，循环永不停止。

代理本身根本没坏。是守卫脚本把“重启中的短暂不可用”误判成了“故障”。摘掉这三个每 2 分钟跑一次的守卫脚本后，代理进程连续 42 分钟零重启，网络立刻稳定。做一次 A/B 实验，十分钟出结论，比埋头查一周链路快得多。

三、任何自动重启脚本，必须带三件套

修复不是“删掉看门狗”，而是给它立规矩。重写后的守卫逻辑只加了三条，但每一条都是必要的：

1. 进程存活检查：探测失败但代理进程还活着、端口还在听，就只记日志、绝不重启——这属于抖动，不是故障；
2. 连续 N 次确认：真的要判定“代理死了”，必须连续 3 次确认，而不是一次探测失败就动手；
3. 冷却窗口：两次重启之间强制间隔 15 分钟，杜绝“刚重启完又重启”。

还有一个格外阴的坑：自己写的监测脚本，命令行里如果带着“代理进程名”一类的关键字，会被 ps/pgrep 误计成代理进程，反过来又干扰守卫的判断。所以监测脚本要么用变量拼接命令，要么直接读 /proc/*/cmdline 精确匹配。

四、排障顺序比技术更重要

这单最大的教训是排查顺序：先看守卫脚本自己的日志（grep -v ' OK ' 过滤掉正常的 OK 行），而不是只看它报出来的健康状态。设备链路、连接数、内存、拨号，全部被逐一排除后才回头看到守卫自己。

把这个套路抽象成一句话：当“自动保护”的行为本身可疑时，先怀疑保护机制，而不是被保护对象。看门狗不是越多越稳，一个写坏了的看门狗，比没有看门狗更危险。

五、这套东西，土拨鼠是怎么帮上忙的

这类“多轮排查、边查边记、最后固化结论”的活，正是长任务最容易翻车的地方——查到后面忘了前面排除了什么。几个对应的设计：

• 排查过程落在工作区记忆里，中间被掐断也能接着上一轮继续，不会从头重问；
• 修复动作有备份与验收的痕迹，改了什么、验证了什么、留了哪些护栏，一眼能对上；
• 真正可复用的教训会沉淀成检查清单，同一个坑不再踩第二次。

想了解完整能力可以先看 功能页；要算一笔省多少的账，定价页 有按量与实际的对照；直接上手就 下载 拿一件真事跑一遍，比读十篇心得有用。

六、一个 30 秒自查

下次你发现“自动化的东西”在反复异常，按顺序问自己：

• 是不是守卫/守护/自愈脚本自己在反复触发？先看它自己的日志；
• 它有没有把“重启中的暂不可用”当成故障？有没有冷却窗口？
• 它判定故障前，有没有做进程存活检查、连续几次确认？

三个问题里中任意一个，基本就能解释大部分“它怎么越自愈越糟”的怪现象。自动化的敌人，常常是自动化自己。