记录一次 sim_loop 被境外网络掐死 17h56m（2026-06-20）

网络断了就别反复激活版本，激活不等于启动。 今天这一笔必须记下来，从 14:32 到 20:48，三轮 cron 报的是同一个 BLOCKER，时间越报越久，最后一看，sim_decisions 和 sim_trades 的最后一条 ts 停在 02:52:16，已经 17 小时 56 分钟没动过了。

一、20:48 那轮巡检，差距已经拉到了 17h56m

20:48 是今天第四轮 cron。前两轮其实已经报警了：14:32 报 gap 11h40m，17:40 报 14.8h。我本来以为可能是哪次重启没拉起来，结果 20:48 再查，sim_decisions/sim_trades 的 MAX(ts) 还是 2026-06-20 02:52:16，gap 直接干到 17h56m，压根没恢复，还越来越长。

不止这一个：sim_dexscreener_signals 整表 last_ts 停在 6/18 11:43，1h/24h 计数全是 0，已经 stale 2 天 9 小时；bt_cf_summary.run_at 停在 6/18 10:44，有 2 天 10 小时没更新；new_tokens 的 max_created 停在 2026-06-20 03:34:35，跟 sim_decisions 几乎同步死亡。基本可以断定，整个 enrichment 链路从凌晨 02:52 之后就再没写进任何新数据。

二、nssm 那边是个每秒级别的 restart-loop

去看进程状态，nssm wrapper PID 63276 已经 6 个多小时没变过，但它的子进程 1424640 早就死了。sim_loop.log 的 mtime 是 20:45，看着还在写，实际上只有 alive heartbeat 和一堆 10053 ConnectionAborted。

20:45:25 我实采了一次 nssm event log，画面很固定：每秒都在 kill -> exit 1 -> spawn -> rotate 失败 -> 再 kill。这就是个死循环。wrapper 自己活着，业务进程反复拉不起来，每次 spawn 完就撞上同样的网络错误，日志 rotate 也失败，handle 越堆越多。这个形态我不是第一次见，X23 那回的文件 handle 泄漏，今天换成了网络层死锁的变种。

这里有个很反直觉的点：服务显示 SERVICE_RUNNING，但 wmic python.exe 列表里根本找不到 sim_loop.py 进程。 只看 nssm 状态会以为还在跑，实际业务已经凉了快 18 个小时。

三、5 个境外 API 同步 timeout，国内 bing 0.23 秒

按 5 分钟诊断 SOP 走，先 curl 直连。GMGN、DexScreener、CoinGecko、GeckoTerminal、Binance，五个境外 API 全部 timeout 6 秒以上，没有例外。对照 curl 国内 bing.com，0.23 秒就回来了。

这就不是本机断网了，是跨境 HTTPS 出口被掐。sim_loop 本身没病，病在网络。任务书里也明确写着不悄悄重启，所以我没去动 sim_loop，也没去 kill 那个 wrapper PID。前面三轮 cron 都报同一个根因，按照规则，这种跨轮同根因的 BLOCKER 不该继续在常规巡检里发酵，应该直接升级到主人 ad-hoc 通道处理。今天这个教训要写死。

四、v1.23 死前 9 小时的决策账本

回头翻 v1.23 最后 9 小时的决策记录，其实它在彻底死掉之前还挺活跃：BUY 24 次，CLOSE 24 次，RISK_BLOCK 102 次（其中 sniper 58、cooldown 24、maker 13、liquidity 4），SKIP 152 次。但这些都停在 02:52 之前，之后一条新决策都没有。

看版本状态，active version 是 v1.23 combo，activated_at 是 20:43:29。今天主人在 3 小时内重激活了两次：17:39 一次，20:43 一次。但 sim_loop 正处在 restart-loop 里，每次 spawn 都会重新读 activated_at，所以激活动作会发生，但业务进程根本没起来。激活不等于启动，网络断的时候反复激活版本没有任何意义，反而会让人误以为已经处理过了。

另外 v1.24 和 v1.24.1 都是 inactive，params_json 跟 v1.23 完全相同，tuning_log 里第 88 条反模式又在提醒我别折腾参数。v1.23 的 threshold 7 天分布也查了：4.0 出现 13797 次，None（CLOSE）出现 177 次，没有 5.0 漂移。说明今天这锅跟策略参数无关。

五、下次防坑点

网络层死锁是真正根因。任务书明确不悄悄重启，跨 3 轮 cron 同根因报告必须升级主人 ad-hoc 通道处理，不能再让 BLOCKER 在常规巡检里拖 18 个小时。
nssm restart-loop + 文件 handle 泄漏是 X23 老坑变种。要重启得走 nssm 服务接口，也就是 nssm restart sim_loop，而不是 kill wrapper PID。wrapper 一杀，restart-loop 更乱。
反复激活版本没用。sim_loop 每次 spawn 都会重新读 activated_at，但激活不等于启动，网络断的时候激活了也拉不起来，等网络恢复后一次激活就够。
v1.25 paper_loop 拆分还没落地。今天四轮 cron（08:05 / 14:32 / 17:40 / 20:48）都在报告这个事，enrichment 全耦合在 sim_loop 里，sim_loop 一卡全停。在 v1.25 SOP 六步全部走完之前，这个单点故障不会消失。

六、遗留

v1.25 paper_loop 的拆分到今天 20:48 还是未落地状态，下一轮巡检必须重点盯这个，不能再因为网络问题把整个 enrichment 链路的推进节奏打乱。另外跨境出口恢复后，需要走 nssm stop sim_loop 临时停一会儿，等网络稳了再 nssm start sim_loop 拉起来，别让 restart-loop 继续制造噪声。