Mihomo Party 开 TUN 后断网，第一步要删配置吗？

不要先删配置。关闭 TUN、关闭系统代理、退出 Mihomo Party，让普通网络恢复；再保存日志和路由表。删配置会丢掉判断 TUN、DNS 和 Fake-IP 的证据。

系统代理能用，TUN 模式不能用是什么原因？

这说明订阅和出站大概率能跑，故障更像 TUN 虚拟网卡、默认路由、DNS 劫持、Fake-IP 或权限问题。先用同一个网址分别测系统代理和 TUN。

Mihomo 的 dns-hijack 写 any:53 就一定生效吗？

不一定。Mihomo TUN 文档说明 macOS / Windows 无法自动劫持发往局域网的 DNS 请求；Linux 上还要看 core 是否有网络管理权限。

Mihomo Party 开 TUN 后断网怎么排查 | 路由表、DNS、Fake-IP 和系统代理 2026

Mihomo Party 开 TUN 后断网，不要先换订阅或重装。把 TUN 和系统代理都关掉，让普通网络回来；系统代理能访问同一个网址、TUN 一开就超时，才进入路由表、DNS、Fake-IP 和权限这条线。

Mihomo Party（GitHub 仓库名也叫 Clash Party）是一个 Mihomo GUI，支持大部分 Mihomo 常用配置修改，内置 Smart core 与 Mihomo core。TUN 相关行为最终以 Mihomo 的 TUN 与 DNS 文档为准。

TUN 断网按现象分三层

先用最小动作把现象分清。不要一边改 DNS，一边改节点，一边开关系统代理；这样日志会变得很难读。

现象	更像哪一层	先看什么
关 TUN 后普通网络仍然不通	系统 DNS、系统代理或旧虚拟网卡残留	系统代理设置、DNS 服务器、默认路由
系统代理能用，开 TUN 后所有域名打不开	TUN 路由或 DNS 劫持	`auto-route`、`auto-detect-interface`、`dns-hijack`
只有部分网站、局域网域名或 NAS 打不开	Fake-IP 过滤或规则命中	`enhanced-mode`、`fake-ip-filter`、规则日志
浏览器不通，但 `ping 1.1.1.1` 有回应	DNS 查询失败	系统 DNS、Mihomo DNS 日志、浏览器 DoH
Linux GUI 开 TUN 后 DNS 仍走 `127.0.0.53`	core 权限或 systemd-resolved	`cap_net_admin`、进程启动方式、DNS 日志

这张表的关键是把“没有网”拆成 IP 层和 DNS 层。能访问 IP 但不能解析域名，优先查 DNS；连 IP 都不通，先查默认路由和 TUN 网卡。

把系统网络救回来

Mihomo Party 断网后，先把系统退回普通网络：

在 Mihomo Party 里关闭 TUN。
关闭系统代理。
退出 Mihomo Party，确认后台 core 进程也停了。
把系统 DNS 改回自动获取，或临时填一个你明确可用的 DNS。
重新连接 Wi-Fi / 有线网络。

Windows 可看：

Get-NetIPConfiguration
Get-DnsClientServerAddress
route print
netsh winhttp show proxy

macOS 可看：

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getdnsservers Wi-Fi
netstat -rn
ifconfig | grep -i utun

Linux 可看：

ip route
resolvectl status
ip link | grep -i tun

普通网络没有恢复前，不要继续改 Mihomo YAML。此时你还不知道是系统代理残留、DNS 残留，还是 TUN 路由没有撤掉。

路由表里要看到什么

Mihomo TUN 文档把 auto-route 描述为自动设置全局路由，让全局流量进入 TUN 网卡；auto-detect-interface 用来自动选择流量出口接口，多出口网卡同时连接时建议手动指定出口网卡。

可用一个很小的 TUN 段做对照：

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

开 TUN 后，路由表应出现指向 Mihomo TUN 设备的默认路由或策略路由。不同系统名字不一样：Windows 可能看到 Mihomo / Wintun 相关接口，macOS 常见 utun，Linux 可通过 ip route 和 ip rule 看表项。

如果设备同时连着 Wi-Fi、有线、Tailscale、WireGuard 或公司 VPN，auto-detect-interface 可能选错出口。此时不要急着换 stack，先停掉其他网络层工具，或在客户端里手动指定实际出口网卡。

DNS 劫持没有命中时怎么判断

Mihomo TUN 文档里的 dns-hijack 会把匹配到的连接导入内部 DNS 模块；同一段文档也提醒，macOS / Windows 不能自动劫持发往局域网的 DNS 请求，Android 开私人 DNS 时也不能自动劫持。

排查时看三处：

检查点	正常信号	异常信号
Mihomo 日志	出现 `[DNS] resolve example.com`	浏览器报 DNS 错误，但日志没有 DNS 记录
系统 DNS	指向本机、TUN 或客户端接管的地址	仍指向路由器、公司 DNS、`127.0.0.53`
53 端口查询	能进入 Mihomo DNS 模块	查询直接发往局域网 DNS

Windows 上还要看浏览器自己的安全 DNS。Chrome / Edge / Firefox 如果单独启用了 DoH，域名查询可能不走系统 DNS 路径。排错阶段先关浏览器 DoH，用系统层 DNS 做对照。

Linux 上要特别看 systemd-resolved。Mihomo Party 的 GitHub issue #1165 记录过一种情况：GUI 启动的 core 没继承 cap_net_admin 能力，导致 TUN 模式的 dns-hijack 失效，系统 DNS 查询仍由 systemd-resolved 处理。这个 issue 不能证明所有 Linux 断网都是权限问题，但它能解释“界面显示 TUN 已开，DNS 仍没有进 Mihomo”的一类故障。

Fake-IP 不是越多越好

Mihomo DNS 文档里，enhanced-mode 可选 fake-ip 或 redir-host，默认是 redir-host；fake-ip-filter 用来指定哪些地址不下发 Fake-IP 映射。TUN 场景里 Fake-IP 很常见，但它不适合所有域名。

一个偏保守的 DNS 段可以这样写：

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.0/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "+.local"
    - "+.home.arpa"
    - "router.asus.com"
    - "time.windows.com"

如果开 TUN 后只有 NAS、打印机、路由器后台、公司内网域名打不开，先把这些域名放进 fake-ip-filter。不要为了一个局域网域名把整个 DNS 段删掉；删掉后你会失去判断 Fake-IP 是否生效的依据。

MetaCubeX/mihomo issue #2023 里有用户贴出的日志，能看到 DNS 查询、DoH 上游、TUN 自动检测接口和 Mihomo Party 工作目录同时出现。这类日志说明 DNS、TUN、规则和 provider 会交织在一起，读日志时要抓第一处异常，而不是只看最后一行超时。

系统代理和 TUN 不要同时抢入口

Mihomo Party 同时提供系统代理和 TUN 开关。系统代理适合浏览器和遵守系统代理的应用；TUN 会接管更底层的流量。两者一起开不一定错，但排错时会增加误判。

建议这样分段测试：

测试状态	命令或动作	结论
只开系统代理	`curl -x http://127.0.0.1:7890 https://example.com -I`	能返回 HTTP 头，说明出站链路和订阅大概率可用
关闭系统代理，只开 TUN	浏览器访问同一网址，再看 Mihomo 日志	失败时优先查路由、DNS 和权限
两者都关闭	浏览器直连同一网址	失败说明系统网络还没救回来

端口号不一定是 7890，以 Mihomo Party 实际监听端口为准。如果你的订阅要同时给 Clash、Singbox、V2Ray 生态客户端导入，排错时可以固定一份兼容 Clash / Singbox / V2Ray 的订阅做基线；但 TUN 断网仍要看本机路由表和 DNS 日志，不能把“订阅能导入”当成“系统接管正常”。

strict-route 什么时候该动

Mihomo TUN 文档说明，strict-route 在启用 auto-route 时执行更严格的路由规则；在 Windows 上，它会添加防火墙规则，阻止普通多宿主 DNS 解析行为造成的 DNS 泄露，但也可能让 VirtualBox 等应用在某些情况下无法正常工作。

所以它不是一个永远打开或永远关闭的开关。排错时按这个顺序做：

只开 auto-route 和 dns-hijack，记录路由表和 DNS 日志。
Windows 出现多网卡 DNS 混跑时，再打开 strict-route 对照。
VirtualBox、Docker Desktop、WSL、公司 VPN 异常时，临时关 strict-route 再测一次。
Linux 上如果 TUN 权限不完整，先处理权限，不要指望 strict-route 修复所有 DNS 问题。

多网卡电脑最容易在这里误判。Wi-Fi、有线、虚拟机网卡、Tailscale、公司 VPN 同时存在时，TUN 能启动不等于默认路由一定走对。

成功恢复要怎么验收

恢复不是“浏览器刷出来一次”就结束。至少做四个检查：

# 1. 原始 IP 连通性
ping 1.1.1.1

# 2. 域名解析
nslookup example.com

# 3. HTTP 访问
curl https://example.com -I

# 4. 路由路径
traceroute example.com

Windows 没有 traceroute 时用：

tracert example.com
Resolve-DnsName example.com

再看 Mihomo Party 日志：

有 TUN 启动记录。
有 DNS 解析记录。
有规则命中和 outbound 记录。
重启客户端后，路由表和 DNS 仍能回到预期状态。

如果重启后又断，优先查自启动权限、旧虚拟网卡、系统代理残留和其他网络层工具的启动顺序。

哪些断网不该从 Mihomo Party TUN 入手

以下场景不在此篇范围内：服务端协议配置、OpenWrt 旁路由、手机端私人 DNS、公司内网强制代理、校园网认证页和虚拟机网桥策略。它们都可能让 TUN 表现出断网，但排查入口不是 Mihomo Party 桌面端的 TUN 和 DNS 字段。

未覆盖的部分：不同 Windows 预览版、macOS 网络扩展权限弹窗、各 Linux 发行版的 systemd-resolved 默认策略，以及 Mihomo Party 后续版本可能调整的 UI 名称。遇到这些差异，以当前客户端日志、官方文档和 GitHub issue 的实际字段为准。