Linux systemd-resolved 与 Mihomo TUN：修复 127.0.0.53 DNS

1 127.0.0.53 与 systemd-resolved 在做什么

在 Ubuntu、Debian、Fedora、Arch 等常见发行版上，桌面与标准服务器镜像往往默认启用 systemd-resolved。它会在本机起一个「stub resolver」，通常监听 127.0.0.53:53，并把 /etc/resolv.conf（或指向它的符号链接）里的 nameserver 写成 127.0.0.53。这样做的目的，是让传统的 getaddrinfo 解析路径仍走 libc 习惯用法，而上游 DNS（DHCP 下发、NetworkManager、手动配置）由 resolved 统一缓存与策略控制。

当你启用 Mihomo（Clash.Meta）的 TUN 时，核心会在内核里新增路由与虚拟接口，并经常配合 dns-hijack、auto-redirect 等选项接管发往 53 端口的流量。此时出现冲突的典型结构是：应用仍向 127.0.0.53 发问，而 TUN/路由表改变后，这个数据包在内核里的转发路径 与 resolved 设想的「本机环回直达」不一致；或者 resolved 的上游被你改成又指回 Mihomo，形成解析环路。另一种常见误判是：系统查询绕开了 Mihomo 的 FakeIP 语义，导致「规则对浏览器生效、对 systemd 服务不生效」，看起来像 DNS 泄漏。

理解了这一层，就不难把它和站内《Linux 安装 Mihomo 与 systemd》里「仅 mixed-port、未接管 DNS」的状态区分开：那篇文章让你先把核心跑起来；本文处理的是「内核已接管，但 stub 仍挡在中间」的进阶叠乘问题。

2 与 Mihomo TUN 叠在一起时的典型症状

下列现象单独出现并不代表一定是 127.0.0.53 问题，但若多项同时出现，建议按后文诊断流程走一遍：其一，打开 TUN 后整机解析间歇变慢或偶发「仅 IP 通、域名全挂」；其二，dig / resolvectl query 显示仍经 127.0.0.53，而 Mihomo 连接日志里看不到对应 DNS 会话或出现异常重试；其三，启用 FakeIP 后浏览器正常，但 apt、curl、Docker、Kubernetes 等仍解析出「真实 IP」或策略与浏览器不一致；其四，在内核日志或 resolved 日志里看到重复转发、超时或「回环」相关告警。

TUN 的总体行为模式可对照《Clash Verge Rev TUN 模式完全指南》：差别在于 Linux 桌面默认多了一层 resolved stub，链路比「应用直连接口 DNS」更长，因此更需要显式对齐「谁在 53 上回答」「谁又负责向上游递归」。

不要用「全局神秘开关」代替定位 直接关掉 systemd-resolved、硬删 /etc/resolv.conf 可能在某些环境能「碰运气修好」，但容易在下次网络切换或软件更新后复发。先看清 resolvectl status 与 Mihomo 的 DNS 模块配置，再决定是劫持 stub 还是调整 stub 的上游。

3 三步诊断：先对齐事实再改配置

第一步：看清 resolv.conf 的真实链路。执行 readlink -f /etc/resolv.conf。若指向 …/stub-resolv.conf，几乎可以认定当前「libc 默认解析」会命中 stub。第二步：看 resolved 如何选上游。使用 resolvectl status（或旧版 systemd-resolve --status），记录各 Link 的 DNS Servers 与 DNS Domain。第三步：对比 TUN 开关前后。分别记录同一命令的输出，并观察 Mihomo 侧 dns 与 tun 段落是否启用了劫持或重定向。

Bash

readlink -f /etc/resolv.conf
resolvectl status
resolvectl query www.example.org
journalctl -u systemd-resolved -n 80 --no-pager

若你在排障时需要把 DNS 日志与连接日志对上时间线，可同步阅读《Clash Meta connection 日志与 DNS 排障》，避免「只看到超时不知道是规则问题还是解析问题」。

4 路线 A（优先）：让 TUN 明确劫持发往 stub 的查询

Mihomo 在启用 TUN 时，可通过 dns-hijack 把目标为 53/UDP、53/TCP 的流量导入核心内置 DNS 处理逻辑。对 systemd-resolved 场景，务必把 127.0.0.53:53 也纳入劫持集合，否则部分查询仍可能在 stub 与 TUN 之间「擦边」而过。下列 YAML 为示意片段：字段名与默认值可能随版本微调，merge 时以你当前 Mihomo 文档为准；须与上文 dns.enable、listen、enhanced-mode 等段落一并审视。

YAML (snippet)

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: false
  dns-hijack:
    - "any:53"
    - "tcp://any:53"
    - "127.0.0.53:53"

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://dns.google/dns-query

这段配置的核心思想是：别假设「any:53」一定等价于覆盖 stub——在部分路由与策略组合下，发往 127.0.0.53 的包仍需单独点名。合并后请重新载入配置，再用第三步的命令验证查询路径是否与你预期一致。

与 FakeIP、DoH 的关系 FakeIP 与防泄漏的完整拼图见《Meta 内核 DoH + FakeIP 最佳实践》。若仅打开 TUN 却未打开 dns.enable 或劫持不完整，常会出现「页面能开、日志不对」的半吊子状态。

5 路线 B：从 NetworkManager / resolvectl 指定稳定上游

有些场景不适合完全依赖劫持：例如你需要 resolved 继续为企业内网域做条件转发，或必须与 DHCP 下发的搜索域共存。此时可以反向操作：让 stub 的上游指向一个不会在 127.0.0.53 上与其打架的地址——常见做法是固定到本机另一个环回口上的 Mihomo DNS 监听地址，或固定到可信递归（会牺牲一部分分流语义，慎用）。

NetworkManager 用户可在连接里设置 ipv4.ignore-auto-dns yes 并手写 DNS；再用 resolvectl dns INTERFACE 地址 验证是否生效。注意：标准 DNS 只声明 IP，不含端口号，若 Mihomo 只监听 127.0.0.1:1053，你需要要么让核心也在 53 端口提供兼容监听（注意与 resolved 抢占端口冲突），要么在本地用 nftables/iptables REDIRECT 把 53 转到 1053——这已超出「纯 YAML」范畴，应在变更前备份规则集。

实践原则：同一台机器上，避免「resolved 上游 → Mihomo → 又回到 resolved」的闭环。改前先画出箭头：谁问谁、谁再问谁。

6 路线 C：调整 stub 监听（高风险，需知后果）

进阶用户会在 /etc/systemd/resolved.conf 中使用 DNSStubListener=no 关闭 127.0.0.53 监听，并把 /etc/resolv.conf 改为指向 /run/systemd/resolve/resolv.conf 等非 stub 形态，以减少一层本地转发。此操作对依赖 resolved 的其他栈（某些容器、企业 VPN 客户端）可能影响面大；升级系统时也可能被维护脚本改回。若你采用此路，请确保仍有明确的上游 DNS，并能在重启后自动恢复，而不是留下空白 resolv.conf。

服务器无桌面、仅跑 Mihomo 作为出口的场景，有时反而更简单：直接用 systemd 服务文档化上游与防火墙，减少对桌面网络栈的耦合。这与《Linux Mihomo systemd 入门》里的服务器思路一致。

远程 SSH 机器上慎改 在仅有一路 SSH、无 IPMI 的环境里，错误的 DNS 循环可能导致你立刻断开会话。请先确保有控制台或备用管理 IP，再动 resolved.conf 与 resolv.conf。

7 TUN、重定向与 FakeIP 的交叉注意点

其一，确认 tun.auto-route、strict-route 与系统原有默认路由不会把「本应走环回的 127.0.0.53」异常拉到隧道里或反之。其二，若使用 redir-host 等模式，DNS 与连接日志的对应关系会变化，排障口令与 FakeIP 场景不同。其三，容器与 systemd-nspawn 往往自带一份 resolv.conf，宿主机修好不等于子环境同步修好，需要在对应 netns 内重复验证。

若你同时开启浏览器 DoH 与系统 stub，会出现「一条路径走 Mihomo FakeIP、另一条路径直连 DoH」的策略分叉，这不是 Mihomo 独有，可与《Chrome / Edge 安全 DNS 与 Clash FakeIP》对照阅读，只是 Linux 上又多了一个 resolved 变量。

8 交付前检查清单

TUN 开启与关闭各跑一遍 resolvectl query，确认行为可解释、无随机超时。
Mihomo 日志中 DNS 与连接记录的时间戳、域名、策略名能互相对齐。
切换节点、切换 Wi‑Fi、睡眠唤醒后仍稳定（桌面常见回归点）。
关键业务（系统更新、容器拉镜像、内网入口）未被你为「修 DNS」而误伤。

排障完成标志 不是「能打开某个网站」，而是在 connection 日志里同一类会话可重复得到一致的解析与策略——这与上文引用篇目的思路一致。

9 常见问题

只劫持 any:53 够吗？在很多 systemd-resolved 桌面不够，请显式补上 127.0.0.53:53 并按路由实际验证。
关掉 TUN 后全机 DNS 恢复慢？检查是否曾改动 NM/resolved 缓存；可尝试 resolvectl flush-caches 与重连网络。
与 VPN 客户端冲突？企业 VPN 常自行写入 DNS 与策略路由；需要决定「谁先接管」并避免双劫持。
能否完全不用 systemd-resolved？可以，但这是发行版级取舍，要接受后续升级与社区文档默认路径与你不同的维护成本。

10 总结

127.0.0.53 本身不是故障，它是 systemd-resolved stub 的设计结果；故障来自它与 Mihomo TUN、FakeIP、系统路由未对齐时的叠乘效应。优先用 TUN dns-hijack 把 stub 问讯纳入核心 DNS 模块，再视需要调整 NetworkManager 与 resolved 上游；关闭 stub 监听是高风险选项，只应在理解全局影响后使用。

相较零散的「复制一段 iptables」方案，把链路画清、按诊断命令逐步验证，反而更省时间。需要图形客户端一键管理 TUN 与订阅时，可从本站下载页选型；与纯命令行 Mihomo 服务并不冲突——按场景组合即可。若你偏好稳定桌面体验而非自行拼劫持规则，成熟客户端通常已把常见 Linux DNS 坑封装成可切换选项。

→ 立即免费下载 Clash，开启流畅上网新体验

Linux systemd-resolved 与 Mihomo TUN：
修复 127.0.0.53 DNS 冲突一步步操作