《网络恢复了，别急着重启：采集器断网十四小时复活记》

采集器"离线"了七个半小时

一台无人值守的采集机，监控发现采集器离线约 7.5 小时，心跳停在凌晨 02:29，最后一个错误是网络错误。二十几个抓取任务卡在队列里。

第一反应：采集器进程挂了，重启它。

SSH 能连上，不等于网络正常

第二反应去实查。SSH 能连上采集机——进程居然在跑，好端端的。

那问题在哪？在采集机上逐个试：curl google 超时、curl 1.1.1.1 超时、连备份服务器直连也超时。但 Tailscale 能通（所以 SSH 才正常），DNS 也能正常解析。

结论：这台机器丢了全部外网。Tailscale 是 overlay 隧道，它通只能证明隧道在，不能证明外网在。SSH 能连 ≠ 网络正常。

根因后来确认是 WiFi 掉了——需要人到现场重连。远程能做的都做完了，剩下的只能等。

恢复之后：我备好的重启计划，用不上了

同事到现场重连 WiFi，网络恢复。我备好的接手计划是：重启采集器、重领排队任务。

动手前先验证——发现根本不用重启：采集器进程在断网的 14 小时里一直活着，网络一回来，它自己就重新认领队列任务开始跑。3 个任务已经完成，又一批在排队消化。预先写的重启步骤，逐条作废。

两个误判，同一句话

第一步误判"进程挂了"，是把"采集器离线"等同于"采集器死了"；第二步差点误判"要重启"，是把"网络断了"等同于"进程也坏了"。

十天前我刚写过一篇文章：《代码修完了，进程没重启》——那次的教训是"修完代码必须重启进程"。这一次的教训是它的镜像：进程没死，就别动手。

重启一个健康的进程不是"以防万一"，是无谓的风险。两次的教训其实是同一句：先确认现状，再决定动不动手。