Mihomo 配置文件没改过，节点也是通的，但打开 TUN 模式之后浏览器显示「无法连接」或 DNS 解析失败——这个问题在 macOS 上尤其高频。macOS 从 Ventura (13.x) 开始对网络扩展和系统文件的权限控制持续收紧，到 2025-2026 年的 Sequoia (15.x) 时，TUN 模式需要闯过的系统权限关至少三道。

权限第一关：全磁盘访问（Full Disk Access）

Mihomo 需要通过 utun 虚拟网卡注入 DNS 设置，并可能修改系统级的 DNS 解析行为。macOS 的 TCC (Transparency, Consent, and Control) 安全框架将这类操作视为受保护的系统文件访问。如果没有 Full Disk Access，TUN 创建成功了但 DNS 请求不会通过它。

去「系统设置 -> 隐私与安全性 -> 全磁盘访问」，确认你使用的 Mihomo 客户端（Mihomo Party.app / Clash Verge Rev.app / 独立 mihomo binary）在列表中且开关为开启状态。如果不在列表中，点 + 添加对应 App。添加后需要完全退出客户端再重新打开才生效。

经验信号：部分 macOS Sequoia 用户在系统升级后，之前已授予的 Full Disk Access 权限会变为「已列出但实际未生效」。最快的检测方法是开关一次权限（关闭 -> 等 10 秒 -> 重新打开 -> 重启客户端）。

权限第二关：网络扩展激活

在「系统设置 -> 通用 -> 登录项与扩展 -> 网络扩展」中，应能看到 Mihomo 相关扩展。如果该扩展显示为灰色或带有「未验证」标记，点击信息 (i) 图标手动批准。

如果此页面根本没有任何 Mihomo 相关条目，说明客户端的网络扩展没有在系统中注册成功。此时：

  1. 完全退出 Mihomo 客户端
  2. 去 Finder 的应用文件夹 > 右键你的客户端 App > 打开（第一次需要通过右键打开才能触发 macOS 的 Gatekeeper 验证流程）
  3. 如果弹出「无法验证开发者」的提示，去「系统设置 -> 隐私与安全性」底部找到「仍要打开」按钮
  4. 打开后，查看网络扩展列表中是否出现了 Mihomo

注意：macOS 的 System Extension（系统扩展）和 Network Extension（网络扩展）是两个层级——前者是更底层的 kext/dext，后者是基于 NetworkExtension 框架的 VPN 配置。Mihomo TUN 使用的是 Network Extension 框架（utun 虚拟网卡 + NEPacketTunnelProvider），不是 System Extension，所以不需要进入恢复模式关闭 SIP 来安装。

权限第三关：确认 DNS 真的指向了 utun

权限都拿到后，终端里跑两条命令验证：

# 1. 确认 utun 接口存在且 Mihomo 已配置 DNS
ifconfig | grep -A5 utun
# 应该看到至少一个 utun 接口有 inet 地址

# 2. 确认系统的 DNS 解析器链中有 utun
scutil --dns | head -30

scutil --dns 的输出中，resolver #1 应该是 utun 接口（显示 if_index: X (utunY)）且 nameserver 地址应该是 Mihomo 配置中 dns 段指定的地址——如果是 192.168.1.1 或 ISP 的 DNS 地址，说明系统 DNS 解析器没有采纳 TUN 设备的 DNS 设置。

macOS DNS 服务覆写：mDNSResponder 的优先级

即使 scutil --dns 显示 utun 是第一个 resolver，macOS 的 mDNSResponder 服务在一些场景下仍然会绕过它直接查询。这是 macOS 特有的行为：

场景mDNSResponder 的行为修复
开启了 iCloud Private Relay全部 DNS 查询走 Private Relay，绕过所有本地代理关闭 iCloud Private Relay（系统设置 -> Apple ID -> iCloud -> Private Relay -> 关闭）
浏览器使用内置 DNS (DoH)Chrome/Firefox 默认开启 Secure DNS，不走系统 DNS 栈Chrome: 设置 -> 隐私与安全性 -> 安全 -> 关闭「使用安全 DNS」；Firefox: 设置 -> 隐私与安全 -> DNS over HTTPS -> 关闭
系统开启了 Limit IP Address Tracking类似 Private Relay 的本地 DNS 匿名化Wi-Fi 网络详情 -> 关闭「限制 IP 地址跟踪」
/etc/resolv.conf 被 DHCP 覆写系统在租约刷新时把 resolv.conf 重新指向路由器 DNSMihomo 配置 tun 段里加 auto-route: true 和 auto-detect-interface: true

检查 Mihomo 本身的 dns 配置段

系统权限都通过了，最后确认 Mihomo 配置文件的 dns 段本身没有问题。一个可工作的最小 dns 配置段 (fake-ip 模式)：

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - tls://8.8.8.8
    - https://dns.google/dns-query
  fallback:
    - tls://1.1.1.1
  fake-ip-filter:
    - '*.lan'
    - 'localhost'

常见的 dns 段问题：

  • enhanced-mode 设为 redir-host 但 DNS 解析路径和 TUN 路由表冲突 -> 换 fake-ip 更稳
  • nameserver 里填了 223.5.5.5（阿里 DNS，延迟低但对海外域名解析不友好）-> 换成 Google 或 Cloudflare 的 DNS over TLS/HTTPS
  • fake-ip-filter 把目标父域误加入了排除列表 -> 检查日志中目标域名是否命中了 filter 规则

如果 Mihomo 日志（拉到 debug 级别）中持续出现 dns resolve 后面跟着 timeout 或 no such host，说明上游 DNS 不通——检查上游 DNS 地址是否可以通过直连或者代理路径访问。

至此如果所有三道权限关卡都已通过、mDNSResponder 的覆写已关闭、dns 配置段也已确认无误，而 DNS 仍然不解析，那就不太可能是系统端的问题了。接下来排查代理节点本身是否在线、订阅配置的 DNS 策略是否被服务端规则覆盖。如果你在使用配套的订阅服务，确认订阅链接是否支持 DoT/DoH 并且 DNS 策略没有与本地 Mihomo 配置冲突。建议使用配套订阅线路来减少订阅端和本地配置之间的参数冲突。

未覆盖的设备与系统

以下情况本文未测试：macOS 上通过 Homebrew 安装的独立 mihomo binary 与通过 GUI 客户端（Mihomo Party/Clash Verge Rev）使用时的权限路径可能不同；基于 Apple Silicon (M1/M2/M3/M4) 和 Intel 芯片的 macOS 在网络扩展行为上可能存在细微差异但本文未做区分测试；macOS 测试版（Developer Beta）的权限行为不在本文覆盖范围内；Linux/Windows 上 Mihomo TUN 的 DNS 问题有不同的排查路径。

相关阅读