一、先看痛点：服务器不会挑你睡觉的时候坏
我们最早是手工盯：站点挂了，要么是半夜被人发现，要么是自己第二天早上打开一看"502"。等发现的时候，已经丢了几个小时的公域流量和潜在客户询盘。人不可能 7×24 在线，但脚本可以。
二、三层探活，而不是"ping 一下就完事"
只测端口通不通会误判——进程在，但内部已经僵死（比如 443 端口还在监听，握手却一直失败）。我们现在的看门狗是三层：
1. TCP 连接探测
先用 TcpClient 试连 80 和 443，连不上直接算挂。
2. HTTP 真实请求
再发一个真实的 HTTP 请求（不是只连端口），看返回是不是 200。注意我们用 curl -Lk 跟随跳转——主站有 http→https 的 301 强跳，裸 curl 返回 301 是正常强跳，不是故障，必须看终点是不是 200。
3. 进程健康检查
确认后端 python 进程存活，并且只有"单一"一个 python.exe，多了说明有并发抢文件或僵尸进程。
核心判断： 判活必须"真连真请求"，别用
netstat 看端口占用来假装探活——那只能证明端口被占，证不了服务活着。三、失败就自动重启，不用你爬起来
三层里任意一层不过，看门狗就：杀掉僵死的 python 进程 → 重新拉起站点计划任务（我们的 WebServer80）→ 等几秒复探。整个过程写进日志，成功失败都有记录。
一句话： 重启是"自愈"，不是"等人工"。人在白天看日志复盘就行。
四、日志怎么查才不瞎
所有动作落到 C:\www\logs\watchdog.log。重点看三类：① 探活失败的时间点；② 重启动作是否成功；③ 有没有 server_fatal.log——只要出现这个文件，说明进程自己判了 fatal，必须人工介入，看门狗重启也救不回。
五、踩过的坑（都是真事）
坑 1 · 443 僵尸监听： 早期后端握手失败却把异常吞了，导致文件句柄（fd）泄漏，443 一直"在监听但握不上手"。修法是让握手失败显式抛错、尽快释放连接，而不是静默吞掉。
坑 2 · netstat 误判： 一度用 netstat 看端口占用当探活，结果端口被僵尸进程占着，一直显示"正常"，实际服务早死了。改成真实 TCP+HTTP 探活后这个问题消失。
坑 3 · 裸 curl 误报： 主站 301 强跳，裸 curl 拿 301 当成"挂了"反复重启。加
-Lk 跟随跳转看终点才对。六、别高兴太早：单点风险与备份
看门狗能救"服务挂"，救不了"机器崩"或"磁盘满"。我们的做法：① 关键脚本多副本；② 每日产出备份到另一台机器（服务器）；③ 渲染这类重活是单点，产出每天往服务器同步一份。看门狗是"减少半夜起床"的工具，不是"免备份"的理由。
给后来者： 纯脚本、零成本、可复制。先拿三层探活模板跑起来，再逐步加自愈逻辑，比一上来写复杂系统靠谱。