macOS 开启 TUN 后内网域名无法解析，DNS 覆写怎么排查

Mac 开启 TUN 后，切换 DNS 覆写导致内网域名无法解析，应同时核对系统 DNS 与 Mihomo 的域名解析策略。系统中显示的 DNS 地址和内核实际使用的上游解析器并不总是同一个值。

涉及环境和症状

该反馈来自 macOS 27.0.1、Clash Verge Rev 2.5.8。用户在启用 TUN 后切换 DNS 覆写，观察到 Wi-Fi DNS 被改为占位地址；所在公司不同办公地点通过 DHCP 分配不同的内网 DNS，使用 system 时读到的地址不再是原有内网解析器，导致私有域名解析失败。

维护者建议按域名配置解析策略。反馈者确认，将目标域名指向多台内网 DNS 的方式可以解决其场景，但希望客户端能自动适应不同办公地点。这不等于所有网络都适合写死同一组内网地址。

先确认是解析失败还是内网连接失败

关闭或开启 TUN 前，分别记录 Wi-Fi 或有线连接使用的 DNS。可以在「系统设置 → 网络 → 当前网络 → 详细信息 → DNS」核对；有工作 VPN 时，一并记录其是否连接。

在终端执行只读命令：

scutil --dns

记录目标内网域名的解析行为，分享时将企业域名与内部地址脱敏。即使域名已经解析成功，仍需验证到内网地址的路由是否可达；DNS 正确不能替代路由检查。

用域名策略指定内网 DNS

先向管理员确认当前办公网络可以访问的内网解析器。按Merge 覆写教程 备份后，在原有 dns.nameserver-policy 中合并所需策略。例如下面的域名和地址都必须换成本单位实际值：

dns:
  nameserver-policy:
    '+.corp.example':
      - 192.0.2.53
      - 198.51.100.53

两个地址仅用于展示结构，不是可用 DNS。保存后核对「当前配置」中策略是否保留，再测试内网域名。若 DNS 设置页也填写了 nameserver-policy，需要同时核对它是否整体替换了 Merge 中的表，参见DNS 覆写开关与合并优先级 。

多办公地点的 DNS 必须在相应网络可达；填入多台地址不能保证自动选出所有场景都正确的解析器。远程办公、分支网络和 VPN 各自的路由也需满足要求。

不要直接把占位地址当作泄漏证据

官方文档说明，macOS TUN 场景可能调整系统 DNS，实际解析还取决于内核与流量接管。仅凭系统设置中出现某个地址，不能证明请求已经发向它，也不能据此认定发生 DNS 泄漏。

2.5.9 新增 TUN「DNS 模式」，但目前这条 2.5.8 反馈没有对应的新版本复测结果。需要调整时先记录原值，结合内核文档的系统 DNS 行为逐项验证，不能把新选项当作已经确认的通用修复。

撤回与当前进展

若修改后影响连接，恢复原 Merge 与 DNS 设置。需要临时恢复办公网络时，先正常关闭 TUN，再按原记录核对系统 DNS；不要在仍运行的代理持续改写设置时反复覆盖。

该问题已关闭，讨论中没有确认一个自动适应多办公地点 DNS 的正式方案。可用的临时处理是配置经管理员确认、在当前网络可达的内网 DNS 策略。

参考：Issue #8501 、Mihomo DNS 配置 、macOS 常见问题 。