Linux 桌面和小主机上，Mihomo TUN 会碰到两层 DNS：Mihomo 自己的 DNS 配置，以及 systemd-resolved 给每个链路保存的 DNS Server、搜索域和路由域。TUN 退出后，如果这些链路状态没有清干净，浏览器、curl、apt 可能继续走旧 DNS。
先判断是不是 systemd-resolved 残留
先不要改 /etc/resolv.conf。很多发行版的这个文件只是指向 systemd-resolved 的本机 stub：
ls -l /etc/resolv.conf
resolvectl status
resolvectl dns
resolvectl domain常见判断表：
| 看到的现象 | 更可能的位置 | 第一条命令 |
|---|---|---|
/etc/resolv.conf 是 127.0.0.53 | systemd-resolved 正在接管系统解析 | resolvectl status |
关闭 TUN 后还有 ~. | 链路路由域残留 | resolvectl domain |
关闭 TUN 后还有 198.18.0.2 | Mihomo fake-ip/TUN DNS 残留 | resolvectl dns |
浏览器不行，curl -x 127.0.0.1:7890 正常 | 系统 DNS 或 TUN 路由问题 | 对比直接 curl 和代理 curl |
| 只有 apt 失败 | apt 走系统解析链路 | resolvectl query deb.debian.org |
127.0.0.53 是本机 stub。它后面可能接运营商 DNS、路由器 DNS、Mihomo DNS，也可能仍保留一个已经不存在的 TUN 链路。只看这一行，容易误判。
关闭前怎么留一份基线？
在 Mihomo TUN 还开着时，先保存一份状态。不要等出问题后再猜原始链路。
mihomo -v 2>/dev/null || true
ip link
ip route
resolvectl status
resolvectl dns
resolvectl domain重点看四个字段：
| 字段 | 正常会出现什么 | 排错价值 |
|---|---|---|
| Link | 可能出现 Mihomo/TUN 对应接口 | 确认 DNS 绑定在哪条链路 |
| Current DNS Server | 可能是 198.18.0.2 或配置里的 DNS | 判断当前查询走哪一个上游 |
| DNS Servers | 每条链路的 DNS 列表 | 看关闭后是否清空 |
| DNS Domain | ~. 表示路由所有域 | 残留时影响最大 |
issue #2565 里可见的测试证据就是这种形态：开启 TUN 后，resolvectl status 中出现 Current DNS Server: 198.18.0.2、DNS Servers: 198.18.0.2、DNS Domain: ~.。这几个值关闭后应该消失。
关闭后哪三条命令最关键？
关闭 Mihomo TUN 或退出客户端后，立刻跑同一组命令。不要先重启机器。
resolvectl status
resolvectl dns
resolvectl domain再测实际解析：
resolvectl query example.com
getent hosts example.com
dig example.com
curl -I https://example.com如果 resolvectl status 里已经没有 TUN 链路 DNS，但 dig 还失败，要继续看防火墙、路由和上游 DNS。若 resolvectl status 里仍有 ~. 或 Mihomo 相关 DNS，问题就集中在 cleanup。
重启服务前后怎么验证？
先记录，再重启。这样你能判断是 systemd-resolved 缓存问题，还是 Mihomo 下一次关闭仍会复发。
mkdir -p /tmp/mihomo-dns-check
resolvectl status > /tmp/mihomo-dns-check/before-restart.txt
sudo systemctl restart systemd-resolved
resolvectl status > /tmp/mihomo-dns-check/after-restart.txt
resolvectl query example.comNetworkManager 用户可以再看一次：
nmcli dev show | grep -E 'IP4.DNS|IP6.DNS|GENERAL.DEVICE'
systemctl status systemd-resolved --no-pager重启后理想状态：TUN 链路消失，~. 不再挂在 Mihomo 相关接口上，系统回到有线网卡、无线网卡或 DHCP 下发的 DNS。resolvectl query 能返回地址，apt update 不再卡在解析阶段。
配置问题还是订阅问题？先别急着换
这类故障容易被误判成订阅不可用。一个简单分界线是：TUN 关闭后才坏，系统代理直连 Mihomo 端口仍能跑，通常不是订阅内容本身。
curl -x http://127.0.0.1:7890 https://example.com -I
curl https://example.com -I第一条能通、第二条不通，说明出站和订阅大概率还能用，系统 DNS 或 TUN 路由更可疑。反过来，如果第一条也不通，再看订阅导入、出站协议、认证和端口。
公司网络、宿舍网和小主机混用时，读者常卡在「客户端排好了，换一套配置又把 DNS 状态搅乱」。如果你需要让多个客户端复用同一份格式，尽量选能直接导出 Mihomo/Clash、sing-box、V2Ray 配置的兼容 Clash / Singbox / V2Ray 的订阅，先减少订阅格式变量，再排本机 DNS。
Mihomo DNS 配置里哪些键会影响判断？
官方 DNS 文档里，排这个问题最常看的不是所有 DNS 字段，而是下面几项：
| 配置键 | 作用 | 排查时怎么看 |
|---|---|---|
enhanced-mode | fake-ip 或 redir-host | fake-ip 模式更容易看到 198.18 段痕迹 |
fake-ip-range | fake-ip 地址池 | 不要一上来改，先确认 cleanup |
nameserver | 默认上游 DNS | 看是否和 resolved 里残留一致 |
fallback | 备用上游 DNS | fallback 开启后还会牵涉 filter 判断 |
listen | Mihomo DNS 监听地址 | 本机查询是否真的进了 Mihomo |
DNS type 文档列出的上游格式包括 UDP、TCP、DoT、DoH、DoQ、system:// 和 dhcp://。如果你在 nameserver 里写了 system://，又让 TUN 修改 systemd-resolved，排错时更要分清「Mihomo 读系统 DNS」和「Mihomo 写系统链路 DNS」这两件事。
2026 cleanup 记录对排错有什么用？
Mihomo issue #2565 的标题直接指向「更新 TUN dependency 以修复 systemd-resolved DNS cleanup」。issue 创建于 2026-02-11，描述的是 Ubuntu 等 systemd-resolved 环境里，TUN 关闭后 DNS 状态清理不完整。
issue 中提到的 teardown 顺序包括：
unsetSearchDomainForSystemdResolved
unsetAddresses
unsetRoute
unsetRules这个顺序解释了为什么 DNS Domain: ~. 值得重点看。只清路由、不清搜索域，系统仍可能把查询送进错误链路。release 页面可见 v1.19.21 记录过「tun 关闭时没有清理 systemd-resolved DNS 设置」的修复；升级前先保存当前复现证据，升级后再跑同一组三段验证。
三段验证清单
把排查切成三段，比「重启一下试试」更容易定位。
| 阶段 | 运行命令 | 合格信号 |
|---|---|---|
| 关闭前 | resolvectl status | 能看到 TUN 链路 DNS，知道 Mihomo 改了哪里 |
| 关闭后 | resolvectl status && resolvectl query example.com | TUN DNS、~.、198.18.0.2 不再残留 |
| 重启服务后 | sudo systemctl restart systemd-resolved 后复测 | 系统回到物理网卡或 DHCP DNS，apt/curl 恢复 |
如果重启 systemd-resolved 后恢复，但下一次开关 TUN 又复发，就把 Mihomo 版本、发行版版本、TUN 配置、三段输出打包保存。此时再升级 Mihomo 或向上游反馈，信息会比一句「DNS 坏了」有用得多。
相关阅读
FAQ
Mihomo TUN 关了为什么 apt 还是解析失败？
apt 走系统解析链路，/etc/resolv.conf 若指向 127.0.0.53，真正上游由 systemd-resolved 管。TUN 关闭后链路 DNS 残留，apt 仍可能拿到错误上游。
/etc/resolv.conf 看起来正常还要查 resolvectl 吗？
要查。127.0.0.53 只是本机 stub 地址，不代表上游 DNS 正常。resolvectl status 才能看到每个网卡和 TUN 链路的 DNS Server、Domain 和 DefaultRoute。
重启 systemd-resolved 会不会影响系统？
会短暂重置本机 DNS 缓存和 resolved 管理的链路设置。桌面或小主机排错通常可以接受；生产机器先记录当前输出，并确认 NetworkManager 或 netplan 会重新下发 DNS。
Mihomo DNS 里 fake-ip-range 要不要改？
先不改。官方 DNS 文档把 fake-ip-range 放在 fake-ip 模式下，常见默认段会和 TUN 行为关联。排 systemd-resolved 残留时，优先看 cleanup，不要先换地址池。
这是订阅问题还是 Mihomo 配置问题？
系统代理能用、只在 TUN 关闭后 DNS 异常时，更像本机 cleanup 或 systemd-resolved 链路状态问题。订阅通常只影响出站可用性，不会直接改 resolved 链路 DNS。