网关回 409 不是服务活着：一次平台冷却与看门狗的判定复盘

早上 06:57，用户一句话：全都连不上了。第一反应是查配置，结果配置是无辜的——服务端整台机器被平台冻住了。

时间线是这样的。06:53，保活脚本最后一次探测正常：两个网关都回 404、SSH 可达。06:53 到 06:57 之间，平台把这台免费机器打进了 cooling down：三个网关全部回 409，SSH 直接被拒，平台还给了原话——machine is cooling down until 2026-10-30T23:01:21Z，换算成本地时间 07:01:21。07:01:48，网关恢复 404。回机器上看，uptime 8 小时连续，这不是重启，是冻结后原样恢复：Xray 在跑、住宅出口容器 healthy、连 VPN 隧道都还是原来那条，出口 IP 没变，前后约 8 分钟。

先分清两种停机。这个平台已知的规则是闲置 30 分钟自动暂停，但当时机器并不闲：用户流量在跑、保活探测每 25 分钟一次也在跑。这次冷却只有约 8 分钟，平台没给原因。把冷却当成闲置暂停去处理，方向就错了——它不需要唤醒操作，到点自己回来，状态还全保留。

真正的收获在复盘看门狗的时候。这次冷却恰好落在两次探测之间（06:53 正常、07:01 已恢复、下一次探测约 07:18），所以没有真的漏报。但把判定逻辑翻出来看，有个洞：旧逻辑是「网关回任何非 000 的 HTTP 状态码，就算活」。问题在于，409 不是我的服务回的，是平台边缘在机器冻结时代答的。假如冷却再长一点、覆盖到某个探测点，日志会写着 up、通知会保持沉默——机器停着，看门狗说一切正常。这类误判平时不发作，只在真出事时发作。

修法是把「活」的定义收紧到应用本身：网关必须回 404（那是我在机器上跑的 Xray 对根路径的特征应答），或者 SSH 探测成功，两者有其一才算存活；409 和其他任何平台代答码一律不算。改完立即实跑一次回读：up、gw=404/404、ssh=1，判定链正常。

教训就一条：探针要验证语义，不要验证连通性。HTTP 有响应，只证明边缘在应答，不证明你的服务在应答。存活判定锚定的应该是应用自己的特征响应，而不是「有个状态码就行」。