macOS 上先把问题切成两层：mixed-port 系统代理是否可用，TUN 是否能创建虚拟网卡并接管 DNS 与路由。Clash Verge Rev 2026 年的 macOS issue #6372 里，现象正是「系统代理正常，TUN 模式超时」；这类故障不能靠反复导入订阅解决。

下面的步骤默认你使用 Mihomo 内核，客户端可以是 Clash Verge Rev、Mihomo Party 或同类桌面壳。不要在公司受管设备上修改 VPN/Network Extension 配置；如果机器由 MDM 管理，让管理员确认允许安装网络扩展。

判断卡在系统代理、权限还是 TUN 路由

把 TUN 关闭，只保留最小系统代理入口。Clash Verge Rev 快速开始文档把系统代理和 TUN 分成两种入口：系统代理改操作系统代理设置，TUN 则安装虚拟网卡来处理不支持系统代理的程序。

curl -x http://127.0.0.1:7890 https://example.com -I
lsof -i :7890
scutil --proxy

如果第一条 curl -x 不通，查订阅、出站、端口和 YAML。系统代理都不通时，TUN 日志里的 DNS 与路由报错只是后续连锁反应。

现象更可能的位置第一条安全检查
curl -x 127.0.0.1:7890 失败订阅、出站、端口或配置语法lsof -i :7890
系统代理通，TUN 打开后全站超时虚拟网卡、路由或 DNS 接管netstat -rn
日志出现 operation not permittedroot、helper 或 Network Extension 授权查客户端权限与 helper
只有部分域名解析异常fake-ip/redir-host、上游 DNS 或规则scutil --dns
访问代理服务器 IP 也进了 TUN路由排除未生效或自连接回环查 route-exclude-address 和连接面板

这张表只做分流，不做最终结论。macOS 网络栈、客户端 helper 和 Mihomo 配置会互相影响，排错时一次只改一个变量。

macOS 权限到底查哪三处？

第一处是 Apple 的 Network Extension 或 VPN 配置授权。NETunnelProviderManager 属于 Network Extension 的隧道配置管理接口；排错时把它当作系统级网络配置，而不是普通系统代理开关。

第二处是客户端自己的 helper 或服务。Mihomo Party 的 macOS 排错文档列出 helper 名称 party.mihomo.helper，并给出 /Library/LaunchDaemons/party.mihomo.helper.plist、/Library/PrivilegedHelperTools/party.mihomo.helper 和 /tmp/party.mihomo.helper.log 等路径。这说明桌面壳常用特权 helper 处理需要更高权限的网络操作。

第三处是 Mihomo 创建 TUN 接口时的系统权限。Clash Verge Rev issue #381 的报错为：

Start TUN listening error: configure tun interface: Connect: operation not permitted

看到这类日志，先不要改 DNS。它指向的是 TUN 接口创建权限，不是 nameserver 写错。

macOS 上可以做这些只读检查：

# 看是否有相关 helper 进程或服务痕迹
launchctl print system/party.mihomo.helper 2>/dev/null | head -40
ps aux | grep -Ei 'mihomo|clash|verge|party' | grep -v grep

# 看系统是否已有 VPN/隧道类网络服务
networksetup -listallnetworkservices
scutil --nwi

launchctl print 只读取状态。不要直接删除 helper，除非你已经准备回滚并确认当前客户端退出。

TUN stack 在 macOS 上怎么选？

Mihomo TUN 文档列出 system、gvisor、mixed 三个 stack。文档倾向在无异常时使用 mixed，但排错时更重要的是固定一个值，拿到可重复的日志。

# redacted: macOS TUN baseline, do not paste secrets here
tun:
  enable: true
  stack: mixed
  device: utun999
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

device 在 macOS 上只能用 utun 开头的名称。不要把它改成 Linux 常见的 mihomo、tun0 或自定义英文名，否则你排到最后会误以为是 DNS 问题。

排错顺序建议这样定：

tun.stack适合什么时候测看到异常后先做什么
mixed首轮基线，TCP/UDP 行为都要观察出错时先保留日志，再切 gvisor 对照
gvisor系统栈疑似受安全软件、路由或权限影响看连接面板是否仍出现自连接或 DNS 超时
system需要贴近系统网络栈定位路由问题查 netstat -rn、scutil --nwi 和接口名

不要同时改 stack、dns-hijack、fake-ip-range 和规则集。四项一起改，日志就失去排错价值。

DNS hijack、fake-ip、redir-host 怎么取舍？

Mihomo DNS 文档说明 enhanced-mode 支持 fake-ip 与 redir-host，默认值是 redir-host。fake-ip 会给域名返回一个假地址池，常见配置使用 198.18.0.0/16 这类测试网段；redir-host 更接近「解析真实地址后再按规则处理」。

# redacted: fake-ip test profile
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  nameserver:
    - https://dns.example/dns-query

fake-ip 的优点是规则分流可观测性强：连接面板里能看到域名映射，日志里也更容易定位 DNS 是否进入 Mihomo。缺点是部分旧应用、内网域名、硬编码校验或局域网发现服务可能不喜欢假地址。

# redacted: redir-host comparison profile
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: redir-host
  nameserver:
    - system://
    - https://dns.example/dns-query

redir-host 适合拿来做对照：如果 fake-ip 下异常、redir-host 下恢复，问题就集中在 fake-ip 映射、过滤列表或应用兼容性。不要马上扩大 fake-ip-filter，用一个域名复现，再加一条过滤。

DNS 选择更适合主要风险验证命令
fake-ip规则命中可观测、客户端连接面板排查内网域名、旧应用、部分证书校验异常dig @127.0.0.1 -p 1053 example.com
redir-host兼容性优先、对照 fake-ip 异常规则链路不如 fake-ip 直观scutil --dns 后访问同一域名
respect-rulesDNS 查询也按规则走需要 proxy-server-nameserver，配置复杂度上升看日志里 DNS 出站组
fallback默认上游失败时备用fallback-filter 会引入额外判断对比同一域名两次解析

Mihomo TUN 文档还提醒：macOS 和 Windows 无法自动劫持发往局域网 DNS 的请求。所以 dns-hijack: any:53 没看到所有查询，并不一定是配置无效；先测本机查询，不要把路由器、手机或旁路由上的请求混进同一轮判断。

路由规则要先查命中，再谈排除

TUN 打开后，auto-route: true 会把全局流量导进 TUN 网卡。auto-detect-interface 会自动选择出口网卡，多网卡、USB 网卡、公司 VPN、远程桌面软件并存时，它可能不是你以为的那张网卡。

看 macOS 当前路由与 DNS：

netstat -rn
route -n get default
scutil --nwi
scutil --dns

再看 Mihomo 连接面板或日志。你需要确认三件事：目标域名是否进入 Mihomo、命中了哪条规则、最后走了哪个出站组。

# redacted: route sanity check
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,PROXY

Clash Verge Rev issue #6495 报告过 macOS 15.6、Mihomo v1.19.20、Clash Verge 2.4.6 下 route-exclude-address 未按预期处理，代理服务器 IP 仍被 TUN 捕获并形成自连接。该 issue 被标为 Invalid 并关闭，不代表每个版本都有同一 bug，但它提醒你：路由排除要用连接记录验证，不能只看 YAML。

如果怀疑自连接，把代理服务器 IP 单独记下来，避免贴出完整订阅：

# redacted: replace 203.0.113.10 with your proxy server IP used for testing
route-exclude-address:
  - 203.0.113.10/32
rules:
  - IP-CIDR,203.0.113.10/32,DIRECT,no-resolve
  - MATCH,PROXY

这里的 203.0.113.10 是文档示例网段。写排错记录时只保留网段或打码 IP，不要把真实订阅节点地址贴到公开 issue。

日志看哪些关键词？

日志要按层读，看客户端权限，再看 TUN 设备，然后看 DNS，最后看规则命中。顺序反了，很容易把权限失败误判成 DNS 失败。

日志片段或信号指向位置第一动作
operation not permitted创建 TUN 接口权限不足查 Network Extension、helper 或 root 权限
failed to create tun device虚拟网卡创建失败退出旧客户端，确认没有旧 TUN 残留
utun 未出现macOS TUN 接口未创建固定 device: utun... 后重启客户端
dns-hijack 没有连接DNS 没进 Mihomo 或走了局域网 DNS用 dig @127.0.0.1 -p 1053 对照
目标 IP 命中 MATCH 后回到同一出站可能自连接加临时 DIRECT 排除并看连接面板
TUN 关闭后 DNS 未恢复DNS/路由清理不完整退出客户端后查 scutil --dns 与路由

Mihomo releases 页面在 v1.19.21 记录过 TUN 关闭后没有清理 systemd-resolved DNS 设置的修复。那是 Linux/systemd-resolved 场景，不是 macOS 直接证据；放到这里的价值是提醒你保存版本号和关闭前后日志，而不是用一句「DNS 坏了」概括。

macOS 上常用的最小日志包：

sw_vers
scutil --dns > /tmp/mihomo-macos-dns.txt
netstat -rn > /tmp/mihomo-macos-route.txt
route -n get default > /tmp/mihomo-macos-default-route.txt

如果用 Mihomo Party，再附上官方文档列出的日志位置：

~/Library/Application Support/mihomo-party/logs/
/tmp/mihomo-party-install.log
/tmp/party.mihomo.helper.log
/tmp/party.mihomo.helper.err

公开求助前先删掉订阅 URL、节点域名、token、external-controller secret 和真实公网 IP。

怎么安全回滚到可上网状态？

回滚不要从删除应用开始，把系统网络恢复到能验证的状态，再决定是否卸载 helper 或网络扩展。

  1. 在客户端里关闭 TUN，保留 mixed-port。
  2. 退出客户端，确认菜单栏或后台进程不再运行。
  3. 打开 macOS「系统设置」里的 VPN、网络扩展或代理配置，删除临时创建的 Mihomo/Clash 配置。
  4. 用 scutil --proxy 确认 HTTP/HTTPS/SOCKS 代理没有残留。
  5. 用 scutil --dns 和 route -n get default 确认 DNS 与默认路由回到物理网卡。
  6. 再运行 curl https://example.com -I 和 curl -x http://127.0.0.1:7890 https://example.com -I 对照。

如果是 Mihomo Party helper 异常，官方 macOS 排错文档给了停用与卸载路径。macOS 11 及以后可以先停掉 helper：

sudo launchctl bootout system /Library/LaunchDaemons/party.mihomo.helper.plist

旧系统文档里还列出：

sudo launchctl stop party.mihomo.helper
sudo launchctl unload /Library/LaunchDaemons/party.mihomo.helper.plist

只有在确认要重装时，才删除这些路径：

/Library/LaunchDaemons/party.mihomo.helper.plist
/Library/PrivilegedHelperTools/party.mihomo.helper
~/Library/Preferences/party.mihomo.app.plist
~/Library/Application Support/mihomo-party

删除前先导出订阅和配置。~/Library/Application Support/mihomo-party 可能含有用户配置与日志，直接删会让后续复盘少掉关键证据。

什么时候该升级内核或换客户端？

满足下面三个条件，再考虑升级 Mihomo 内核或换客户端壳：系统代理基线能通；权限、DNS、路由都按上面步骤留了日志；同一份配置在另一个客户端或旧版本表现不同。

升级前记录版本：

mihomo -v 2>/dev/null || true

Clash Verge Rev issue #6372 记录的环境是 macOS 26.1 与 v2.4.7+autobuild.0225.49fd3b0，系统代理正常但 TUN 超时。issue #6495 记录的是 macOS 15.6、Mihomo v1.19.20、Clash Verge 2.4.6 下路由排除行为异常。你不需要照搬这些版本结论，但可以照搬它们的报告方式：版本、系统、最小配置、日志、连接面板截图。

如果升级后恢复，保留旧配置和新配置差异。如果升级后更糟，按上一节回滚到系统代理基线，不要继续叠加 DNS 与规则修改。

相关阅读