我太懂这种随机断连的糟心了——毕竟靠SSH干活的时候，突然连不上真的能打断整个工作节奏。咱们一步步来拆解排查，先从最容易验证的点入手：

一、先确认断连时的双向网络状态 #

当连接突然断掉时，先别着急重启VM，先两边都查一下基础状态：

• macOS主机端：
  1. 打开终端，持续ping虚拟机的IP：ping <VM_IP>，看看是完全丢包还是偶尔有响应；
  2. 查路由表，确认到VM网段的路由是否还存在：route -n get <VM_IP>，如果返回“not found”那就是路由丢了；
  3. 打开活动监视器，搜UTM相关进程，看看是不是进程卡死、CPU占用飙升或者内存溢出——有时候UTM的网络服务进程挂了也会导致断连。
• Fedora VM端：
  别用SSH，直接在UTM的VM控制台窗口登录进去：
  1. 用ip addr看网卡状态，比如eth0是不是还处于UP状态，IP地址有没有丢失；
  2. ping一下共享网络的网关（一般是UTM分配的，比如192.168.64.1这类），如果连网关都ping不通，那是VM这边的网络出了问题；
  3. 查系统日志找线索：journalctl -u NetworkManager -f（实时看NetworkManager的日志），或者dmesg | grep eth0看看有没有网卡链路断开、驱动报错的信息。

二、排查UTM共享网络的稳定性 #

共享网络模式是UTM自己搞的VLAN，可能是这里出了问题：

• 先临时切换成桥接模式用一段时间，看看还会不会断连。如果桥接模式完全正常，那大概率是共享网络的实现有bug；
• 检查UTM版本，是不是用了旧版本？去官网看看更新日志，有没有修复过类似“随机断连”的问题，升级到最新版试试；
• 试试只重启UTM（不用重启VM），看能不能恢复连接。如果可以，那问题出在UTM的网络服务进程，不是VM本身的问题。

三、排查Fedora Server的网络配置 #

服务器版也可能有小细节导致断连：

• 检查NetworkManager的自动连接设置：nmcli con show <你的网卡名>，看看connection.autoconnect是不是设为yes，另外ethernet.power-management最好设为no（省电模式可能会让网卡休眠）；
• 临时关闭防火墙测试：systemctl stop firewalld，然后用一段时间看还会不会断。如果没问题了，那就是防火墙规则不小心挡住了流量——之后再调整规则就行；
• 看看有没有DHCP续租的问题：Fedora默认用DHCP的话，会不会续租失败导致IP丢失？可以改成静态IP试试，避开DHCP的坑。

四、排查macOS的网络干扰 #

macOS这边的软件也可能影响到UTM的共享网络：

• 断连时看看是不是切换了Wi-Fi/有线网络，或者有没有VPN、代理软件在运行？这类软件可能会修改路由表，干扰UTM的VLAN网络，暂时关掉试试；
• 重置macOS的网络栈：比如跑sudo ifconfig utm0 down && sudo ifconfig utm0 up（UTM的共享网络接口一般叫utm0），看能不能恢复连接，不用重启VM。

五、终极手段：抓包分析 #

如果前面的方法都没找到问题，就用抓包工具看数据包的流向：

• 在macOS上用tcpdump -i utm0抓包，过滤VM的IP：tcpdump -i utm0 host <VM_IP>，看断连时有没有ARP请求，VM发的包能不能到主机；
• 在Fedora VM上用tcpdump -i eth0 host <主机IP>抓包，看主机发的ping/SSH包能不能收到，VM的响应能不能发出去。通过抓包能精准定位是哪一步丢了包。

备注：内容来源于stack exchange，提问作者mxk