本文目录
只有这组日志才适合固定出口接口
这篇文章处理一个很具体的故障：Intel Mac 连接 iPhone 个人热点后，系统直连正常，Clash Verge Rev 开启 TUN 却无法联网。官方 issue #7576 记录的环境是客户端 v2.5.2 与 Mihomo v1.19.29，其他 Mac 只有出现相同日志时才适合照此排查。
关键不是网页显示超时，而是 TUN 刚启动时依次出现 get empty name、<invalid>、interface not found，随后才出现 dns resolve failed。它表示自动检测出口时先拿到了空接口，DNS 和代理连接因此没有可用出口。
先确认是否属于同一问题
| 现象 | 判断 | 下一步 |
|---|---|---|
| 关闭 TUN 后系统直连立即恢复 | 节点和系统网络至少不是一起失效 | 继续检查出口接口 |
| 日志先出现 get empty name 或 <invalid> | 自动检测没有及时取得出口 | 查询当前物理网卡 |
| 日志只有 operation not permitted | 这是权限或服务模式问题 | 不要修改出口接口 |
| 系统代理和 TUN 都无法连接 | 可能是节点、订阅或内核故障 | 先处理共同故障 |
- iPhone 个人热点为 Mac 提供当前网络出口
- macOS 物理网卡route 命令显示真实 interface
- Mihomo TUN使用该接口发送 DNS 与连接
- 目标网站完成解析、规则匹配和访问
自动检测在第二步取得空值时，后续 DNS 与出站都会失败；固定接口只适用于该日志特征。
用系统路由查出热点正在使用的网卡
先关闭 TUN，让 macOS 回到可以直连的状态，再在终端查询一个公网地址的路由。命令输出中的 interface 才是此刻真正承载热点流量的物理网卡，不要根据别人的截图猜名称。
route -n get 223.5.5.5只记录本机实际结果
确认直连可用
关闭 TUN 和系统代理，用浏览器打开一个普通网页，避免读到故障状态下的路由。
查找 interface 行
issue 报告者看到的是 en0，但 Wi-Fi、USB 网卡和以太网可能得到不同名称。
重复执行一次
断开再连接手机热点后重新查询，确认接口名称没有变化再写入覆写。
在 Merge 里只覆写两个字段
Mihomo 的 interface-name 是顶层出站接口，auto-detect-interface 则放在 tun 下。打开当前 Profile 的 Merge 或覆写配置，只加入这两个键；不要复制 issue 里的整段 TUN、DNS 或 IPv6 配置，以免把原来能用的设置一并替换。
interface-name: en0
tun:
auto-detect-interface: false这里的 en0 只是示例。也不要把它写到 tun.device：官方文档说明 macOS 的 TUN 设备名以 utun 开头，而 interface-name 指的是 Mihomo 实际向外发送流量的接口，两者用途不同。
重启核心后先看日志，再测 DNS 和网页
保存覆写并通过配置校验后，完整重启一次核心，再开启 TUN。先看新产生的日志，不要只看开关颜色；接口错误消失后，再发起一次新的 DNS 查询和 HTTPS 访问。
按同一顺序验证
重载当前配置
确认仍选中原 Profile 和原节点，不同时更换订阅、DNS 或代理模式。
重新开启 TUN
从本次启动位置开始读日志，检查是否还出现 <invalid> 或 interface not found。
发起两类请求
先打开一个普通网页，再查看连接页是否出现对应域名、规则和实际出口。
关闭 TUN 做对照
确认系统直连仍能恢复，避免把一次缓存命中误判为修复完成。
空接口与 interface not found 都消失，网页恢复
固定接口已避开本次自动检测失败，继续完成切网验证。
仍提示 interface not found
接口名称写错或已经变化，关闭 TUN 后重新查询系统路由。
接口错误消失，但仍是 dns resolve failed
停止增加 DNS 字段，撤销覆写后按独立 DNS 问题排查。
配置校验失败
检查 interface-name 是否位于顶层，以及 tun 下的缩进是否为两个空格。
固定接口后，切换网络要重新检查
手动指定接口会停止自动检测。它适合暂时稳定手机热点环境，但从热点切回家庭 Wi-Fi、USB 网络或以太网后，原接口可能不再是默认出口。若忘记更新，表现仍会是 TUN 开着却无法建立新连接。
网络变化后的处理
| 查询结果 | 处理 |
|---|---|
| interface 与覆写值相同 | 保留当前设置，再测试 DNS 和网页 |
| interface 已变成另一个名称 | 关闭 TUN，更新 interface-name 后重启核心 |
| 以后需要频繁切换网络 | 删除固定接口覆写，恢复自动检测并观察问题是否重现 |
| 同时运行另一款 VPN 或 TUN | 先分别关闭测试，不用一个固定值掩盖路由冲突 |
无效时删除覆写，退回原配置
如果固定正确接口后仍然失败，说明当前故障不只来自自动检测。不要继续添加来源不明的 DNS、路由或脚本设置，先恢复到修改前的 Profile。
完整回退顺序
关闭 TUN
等待系统普通网络恢复，再修改 Merge，避免旧核心继续占用故障路由。
删除两个覆写键
移除顶层 interface-name 和本次加入的 tun.auto-detect-interface，恢复修改前内容。
重新载入原 Profile
保持原节点和规则，用系统代理完成一次访问，确认基本连接仍可用。
保留脱敏日志
记录 macOS、客户端和内核版本，以及开启 TUN 后第一条错误，提交到对应官方 issue。
五项检查确认热点下的 TUN 已恢复
最终验证清单
- 关闭系统代理、只开 TUN 时，浏览器与终端都能产生新连接
- 日志不再出现 get empty name、<invalid> 或 interface not found
- 连接页能显示预期域名、规则与代理或直连出口
- 断开并重新连接同一热点后，接口名称和覆写仍然一致
- 关闭 TUN 后系统直连立即恢复，不需要重启 Mac