TL;DR：OpenWrt 上不要把 DNS 链路接成环。常见稳定顺序是：终端通过 DHCP 拿到 OpenWrt 地址，dnsmasq 接住请求，再转给 Mihomo DNS listen；LAN 本地域名和路由器自身请求单独处理。
OpenWrt、dnsmasq、Mihomo 三者都能处理 DNS，所以配置界面看起来很自由。问题也在这里：一旦 DHCP 下发、dnsmasq 转发、Mihomo 监听和透明接管混在一起，日志会互相打架。排查时先把链路收窄，别急着加备用 resolver。
推荐排查链路
终端 → OpenWrt LAN IP:53(dnsmasq) → 127.0.0.1:7874(Mihomo DNS) → 上游 resolver这条链路的好处是：
- DHCP 主机名仍由 dnsmasq 管。
- 路由器管理域和内网设备容易做例外。
- Mihomo 只负责它擅长的规则解析和上游选择。
- 日志能分清请求从哪一层进入。
如果你让终端直接问 Mihomo DNS，也能跑，但 NAS、打印机、.lan 主机名、路由器本机服务会更难照顾。
第一步：看终端实际拿到什么
不要只看 OpenWrt 后台。到终端上确认 DNS：
nslookup openwrt.lan
nslookup example.comWindows 再看：
ipconfig /allmacOS 可以看：
scutil --dns你希望看到 DNS 服务器是 OpenWrt 的 LAN 地址。若这里出现主路由、运营商 DNS、公共 DNS 或 IPv6 DNS，说明请求根本没按预期进入 dnsmasq。
第二步：dnsmasq 只指向 Mihomo
排查阶段，把 dnsmasq 的上游收敛到 Mihomo DNS listen，例如 127.0.0.1#7874。不要同时保留多个公共 DNS，否则一部分请求可能被 dnsmasq 自己发出，Mihomo 日志里看不到。
同时保留本地解析：
- DHCP 租约主机名。
- 路由器管理域。
- NAS、打印机、摄像头等固定内网域名。
- 需要直连访问的公司或家庭内网域。
这些例外应该在 dnsmasq 或 Mihomo fake-ip filter 里明确写出，不要指望 final 规则兜底。
第三步：Mihomo DNS listen 不要和 53 抢端口
OpenWrt 上 53 端口通常已经被 dnsmasq 使用。Mihomo DNS listen 建议用本机高位端口，例如：
dns:
enable: true
listen: 127.0.0.1:7874然后让 dnsmasq 转给它。若 Mihomo 也监听 0.0.0.0:53，很容易和 dnsmasq 冲突，或者让客户端绕过 dnsmasq 直接进 Mihomo，导致本地域名失效。
第四步：处理透明接管和 hijack
TUN、redir、iptables hijack 都可能把 53 端口流量重新带到 Mihomo。排查时先确认一件事：dnsmasq 到 Mihomo 的请求不要再被劫回 dnsmasq，形成环。
症状通常是：
- DNS 请求延迟很高。
- 日志里同一个域名重复出现。
- 路由器 CPU 突然升高。
- 内网域名偶尔解析到 fake-ip。
遇到这些情况，先关闭 DNS hijack，只保留 dnsmasq 转发。链路稳定后，再决定是否需要接管其他设备的硬编码 DNS。
LAN 例外要写清楚
家庭和小办公室环境里，LAN 例外比远端 resolver 更重要。建议至少处理：
| 类型 | 示例 | 建议位置 |
|---|---|---|
| 路由器管理域 | openwrt.lan | dnsmasq 本地 |
| DHCP 主机名 | nas.lan | dnsmasq 本地 |
| 固定内网服务 | printer.lan | dnsmasq 静态记录 |
| 公司内网域 | corp.example | Mihomo 或 dnsmasq 例外 |
| fake-ip 排除 | *.lan | Mihomo fake-ip-filter |
如果内网域名进入远端解析，轻则查不到，重则拿到意外地址。不要把所有域名都交给远端 resolver。
最后验收
用三个样本验收：一个公网域名、一个内网主机名、一个你明确希望走特定策略的域名。分别看终端结果、dnsmasq 日志和 Mihomo 日志。三边都能对上，才说明顺序正确。
如果只看网页检测，很容易被浏览器 DoH、缓存和 CDN 影响。路由器 DNS 排查要靠链路证据，不靠单次网页截图。