macOS 切换网络后 Clash Verge 无法连接，重启才恢复怎么办

Mac 从 Wi-Fi 切换到手机共享网络，或断线后重新连接时，Clash Verge Rev 偶尔无法继续代理，退出后重新启动才恢复。这种情况应先记录网络切换完成后的系统状态，避免重启后原本的错误现场消失。

涉及版本与设置

该反馈为 Apple Silicon、macOS 27.2、Rev 2.5.10，使用服务模式，同时开启 TUN、系统代理与系统 DNS 设置，系统代理守卫关闭。TUN 使用 gVisor，自动路由与自动检测出口均开启。

用户在故障附近记录到三类错误：

这些错误并不等于已经找到同一个根因。原反馈没有在故障持续时取得完整的代理、DNS 快照，也未确认每次断线都由同一条错误导致。

第一步：先确认新网络已经连通

进入 macOS「系统设置 → 网络」，确认当前实际使用的 Wi-Fi、以太网或手机 USB 网络已经连接。手机共享网络切换过程中，设备出现并不等于网络服务已经取得可用连接。

记录切换前后的网络类型、出错时间和客户端显示的实际端口。尽量先保持原节点、规则与 TUN 设置，不要在一轮排查中同时换订阅、改 DNS 和切换协议栈。

若新网络本身尚未连通，先处理网络连接；反复重启代理不能代替确认当前网络是否可用。

第二步：重启前保留代理和 DNS 状态

打开「终端」，执行以下只读命令：

scutil --proxy
scutil --dns
networksetup -listallnetworkservices

分别记录系统代理是否启用、主机与端口是否对应客户端，以及 DNS 解析配置和系统网络服务名称。结果可能包含内部域名或网络信息，公开反馈前需要脱敏。

如果要核对某个服务的 DNS，必须使用列表中的完整服务名。例如，只有列表确实显示 iPhone USB 时，才使用：

networksetup -getdnsservers "iPhone USB"

不要把示例中的服务名照搬到其他电脑。原反馈中，事后系统列出的服务名与出错命令使用的名称不同；这提供了核对方向，但事后差异不足以证明故障瞬间也是相同状态。

第三步：比较客户端、服务和系统状态

在客户端日志中核对当前是否仍为 Service 模式、是否出现服务请求超时，以及 TUN 出口是否随网络切换发生变化。按日志导出教程 保留切换前后相同时间窗，不必上传整天的连接日志。

系统代理开关显示开启，不代表当前活动网络服务已经成功写入代理；显示关闭，也不一定代表系统实际没有代理。若系统已启用而开关状态不一致，可继续按macOS 系统代理开关异常排查 比较主机和端口。

官方 macOS 文档说明，TUN 运行时客户端可能修改系统 DNS，关闭 TUN 时恢复。因而切换网络后的 DNS 错误应与 TUN 状态一起记录，不能仅凭某个 DNS 地址就判定设置被恶意篡改。

第四步：保存现场后恢复连接

完成记录后，如果可以中断当前会话，从菜单栏正常退出 Clash Verge Rev，等待退出完成，再启动一次。原反馈中，该方式恢复了代理访问；这属于临时恢复经验，不能证明之后每次切换都会正常。

重开后核对三项结果：当前网络服务仍连接、系统代理的主机与端口正确、实际使用的软件能够联网。只验证客户端内置测速，不足以覆盖系统代理与 TUN 的全部路径。

单独重新开关系统代理是否能恢复，在该反馈中尚未得到验证，不应写成已确认修复。也不要为此删除 iPhone USB 等网络服务、永久固定 DNS，或在不了解用途时重装整个网络配置。

如何继续定位与撤回测试

后续若需要比较不同模式，先备份配置，记录各开关原状态，在没有重要网络会话时一次只改变一个条件，测试结束恢复原设置。公司 VPN、受管理代理或特殊 DNS 应保留原配置，不覆盖为个人网络参数。

如果每次重启后很快再次失败，保留本次客户端版本、内核版本、服务模式、网络服务列表与脱敏日志，停止反复切换。客户端与内核能否启动、网络服务能否写入代理、DNS 是否正确生效，应分别判断。

当前进展

问题仍开放，暂无已确认修复版本。日志中的无活动网络服务、DNS 读取失败和服务超时都需要结合当时的系统快照继续定位，不能认定它们必然属于同一个缺陷。

参考：问题记录 、官方 macOS 常见问题 。