1 何时更适合 Mihomo 的 redir-host DNS
Fake-IP 把应用看到的是内核分配的虚拟网段，再由连接阶段的规则决定真实目标，配合 Sniffer 往往最省事；但它要求整条链路都认可这种「先假后真」的方式。某些老的桌面程序、局域网发现类应用、或对 PTR/真实 IP 有洁癖的场景，会出现解析与连接表现分裂。此时把 dns.enhanced-mode 换成 redir-host，让 DNS 直接回答真实记录，常常一次治好「软件能用但浏览器不行」或「同一台机器有的进程走代理、有的死扛直连」之类的怪问题。
redir-host 的代价是：你更依赖上游 nameserver 是否干净、延迟是否稳定，以及遇到跨境解析被污染时，有没有可靠的 fallback 路径。换句话说，Fake-IP 把复杂度藏进内核调度，redir-host 则把复杂度摆回「DNS 分层设计」本身——但也是本文要给你的那份可复制 YAML 能解决的。
若你已经在用 Fake-IP 且一切正常，不必强行改成 redir-host；只有在「不能或不想全程 Fake-IP」时，才优先阅读本文，并与《彻底防止 DNS 泄漏：Meta 内核 DoH + FakeIP 最佳实践配置》对照理解差异，而不是把两篇的片段盲目拼在一起。
2 redir-host 下的解析链路：谁该干什么
在 Mihomo / Clash Meta 中，可以把 DNS 模块理解成「分流前的第一道门」。系统或 TUN 把查询送到内核监听的地址后，内核按域名与策略选择用哪一组上游；nameserver 通常承担「默认可直连的那些解析」，负责国内常用后缀、CDN 与运营商友好解析；当结果被判定可能遭污染、或主解析超时失败时，再走 fallback 里的境外 DNS、DoH、或你信任的中立解析。
redir-host 不会给应用塞一段虚假地址，因此应用随后发起的 TCP/UDP 连接目标，就是解析得到的真实 IP。规则里基于 IP 的条目（例如 GeoIP、自定义 IPCIDR）会与 DNS 结果强相关：若 DNS 先给了被投毒的地址，后面再怎么改规则也只能在错误目标上打转。这就是要把 nameserver 与 fallback 拆开写、并用 fallback-filter 明确「什么时候相信 fallback」的根本原因。
3 第一步：启用 DNS，并锁定 enhanced-mode 为 redir-host
打开 dns 段，至少要明确 enable: true、监听地址与 enhanced-mode: redir-host。listen 常见为 0.0.0.0:53 或带端口的本机地址，需与客户端「接管 DNS」或操作系统的上游设置一致。若你同时启用 IPv6，记得双栈下仍有程序会优先走 AAAA；此时要么保证 IPv6 路径也进隧道，要么在系统侧与内核策略里一并规划，否则日志里会像 DNS「时而对时而错」。
prefer-h3、use-hosts、use-system-hosts 等开关保持默认大多可用；如果你维护 large hosts 或内网自建域名，再按需打开。核心原则是：redir-host 下任何会改变「最终返回给应用的 IP」的选项，都要和后面的 nameserver 设计一起审视，避免 localhost 或内网域名被错误送去境外上游。
dns:
enable: true
listen: 0.0.0.0:1053
ipv6: false
enhanced-mode: redir-host4 第二步：写 nameserver——日常解析的主干道
nameserver 列表放你「期望直连就能问到的」DNS：例如运营商默认、国内公共解析、或延迟低的 Anycast 节点。写法既可以是简单的 1.1.1.1，也可以是 DoH URL；DoT 在部分环境里更抗干扰。关键是：nameserver 不要只跟风堆境外地址——在 redir-host 模式下，主解析太慢或不稳定，会直接把卡顿暴露给每一个应用。
需要把某些后缀固定到专用解析时，用 nameserver-policy 点对点覆盖。例如公司内网域走内部 DNS、流媒体域走指定 DoH，可以减少误判与绕路。策略匹配的优先级要心里有数：越具体的后缀应越早被命中，避免被泛匹配提前截了胡。
如果你担心「国内 DNS 对个别海外域返回污染」，不要急着把所有查询硬塞进境外上游——那会带来 CDN 次优路由与更高延迟。更稳妥的做法是保持 nameserver 克制，把清洗任务交给下一节的 fallback 与 fallback-filter，让内核只在触发条件时换道上高速。
default-nameserver:
- 223.5.5.5
- 119.29.29.29
nameserver:
- 223.5.5.5
- tls://dns.alidns.com
nameserver-policy:
"geosite:cn":
- https://dns.alidns.com/dns-query5 第三步：fallback 与 fallback-filter——何时启用第二套解析
fallback 里通常放境外或你信任的解析源，用于在主解析疑似被污染、返回凑巧落在已知坏段、或匹配 fallback-filter 中的 GeoIP 规则时「再问一遍」。Clash Meta 系列内核会在 nameserver 应答不符合可信判定时尝试 fallback，具体行为随版本迭代略有差异，但设计思想稳定：主解析求快，副解析求真。
fallback-filter 常见组合包括 geoip（例如对中国大陆 IP 存疑时回退）、geoip-url 数据源、ipcidr 私有与虚拟段黑名单、以及 domain 列表。你可以把已知的污染敏感域直接列进 fallback 触发集合，减少「第一次就被带到钓鱼 IP」的机会。与此同时，fallback 也不要只求「远」：延迟与可达性同样重要，DoH 被封锁时要准备可替换的 IP 直连或第二入口。
实战建议：先开启日志观察某几个敏感域在主解析与 fallback 上的返回差异，再微调 filter。盲目复制「大全」配置往往会把正常国内站也拖进慢路径，反而让用户误以为「Mihomo 卡顿」。
fallback:
- https://dns.cloudflare.com/dns-query
- tls://8.8.8.8
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
domain:
- +.google.com
- +.facebook.com
- +.youtube.com6 第四步：proxy-server-nameserver 单独解析订阅与节点域名
订阅链接里的主机名、以及节点线路里写的域名，本质上也要先解析成 IP。若这一步误用被污染的 nameserver，你会看到「测速全红」「更新订阅失败」但网页还能凑合打开」的分裂症状。为此 Mihomo 提供 proxy-server-nameserver（或同类字段，视你所用的 Meta 分支与文档版本措辞而定），让「解析代理本身」走一套你信得过的上游，常见写法是直接指向云端 DoH 或 TLS DNS。
把它理解为：nameserver 服务普通站点，proxy-server-nameserver 服务「梯子自己的钉子」；fallback 则是对普通站点第二意见的兜底。三条链混用同一台慢速或不可靠的解析，会在 redir-host 下被放大成「开关键站点就卡、看日志全是超时」。
proxy-server-nameserver:
- https://dns.google/dns-query
- tls://1.1.1.17 拼起来的完整 YAML 骨架（按上文顺序对照改）
下面片段把前几步拼成一份可读模板；请按你的运营商、地区封锁与订阅源替换其中的地址，并在发布后用手机与桌面各跑一次真实业务验收。不要把模板当作「永久最优解」——DNS 环境会变，学会看日志微调比保存一份百年不变的配置更重要。
dns:
enable: true
listen: 0.0.0.0:1053
ipv6: false
enhanced-mode: redir-host
default-nameserver:
- 223.5.5.5
- 119.29.29.29
nameserver:
- 223.5.5.5
- tls://dns.alidns.com
nameserver-policy:
"geosite:cn":
- https://dns.alidns.com/dns-query
proxy-server-nameserver:
- https://dns.google/dns-query
- tls://1.1.1.1
fallback:
- https://dns.cloudflare.com/dns-query
- tls://8.8.8.8
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
domain:
- +.google.com
- +.facebook.com
- +.youtube.com8 验证步骤与常见解析异常对照
改完 YAML 后不要先冲去打满规则，按最小闭环验证：① 系统 DNS 确实指向内核监听；② 浏览器已关闭自带 DoH；③ 日志里能看到查询走哪组上游；④ 敏感域在主解析与 fallback 之间的返回是否符合预期。可以挑两三个你每天都在用、且历史上容易出问题的域名做标杆，避免「换来换去却不知道有没有变好」。
若仍出现异常，优先对照《Clash Meta 连接日志与 DNS 分流排障》看连接阶段与解析阶段各是谁在报错；IPv6 半开、公司 VPN 分隧道、安卓专用 DNS 等，也会复制类似的「看似 DNS、其实是路由」的症状。把变量一项项关掉，比并发改五处配置更快定位。
- 订阅域名解析失败： 先查
proxy-server-nameserver是否可达，再测 DoH 是否被阻断。 - 国内站拖慢： 检查是否把过多后缀逼进境外 fallback，或 fallback-filter 过宽。
- 海外站偶发跳到错误页： 提高对污染段的 filter 覆盖，并确认主 nameserver 没有被强制全局代理。
- 日志疯狂重试： 减少不可达上游的数量，保留 1–2 个高质量入口，延迟与失败率会同时下降。
9 常见问题
redir-host 和 fake-ip 在 DNS 配置上最大的差别是什么？
fake-ip 向应用返回内核分配的虚拟地址，再在连接阶段按规则做真实解析；redir-host 让 DNS 阶段就得到真实 IP，更依赖上游 nameserver / fallback 的准确性与抗污染能力，因此要更认真拆分两条链，而不是只拷一份「全网通用 DNS 列表」。
可以把 DoH 全部塞进 nameserver 吗？
可以，但不总是划算。DoH 走 HTTPS，失败模式与直连 UDP 不同；在 redir-host 下，所有应用的首次连接都在等它。更常见的做法是 nameserver 以低延迟可靠解析为主，DoH 放在 fallback 或策略域名上，用于对抗污染而不是日常负重跑。
为什么一定要重视 proxy-server-nameserver？
解析代理服务器主机名时若错误地走污染 DNS，会导致连不上节点；把它单独指向可信上游，是减少订阅更新失败与节点超时的高频修复项，和「普通站点走 nameserver」是两件事。
10 总结
Mihomo（Clash Meta）在 dns.enhanced-mode: redir-host 下，真正的关键是把 nameserver、fallback、fallback-filter 与 proxy-server-nameserver 的责任何在纸上划清：主解析负责快与省，副解析负责在触发条件时纠错，代理域名不让脏解析拖垮整条链路。比死记字段名更重要的是用日志验证「这一问到底走了哪条上游」，否则复制再多 YAML 也只是安慰剂。
一些纯命令行或极简内核发行版也能跑 Meta，但在 redir-host 场景里你往往要写更多片段、自己管 systemd 与权限；图形客户端则把 DNS 接管、TUN 与配置编辑合在一起，减少「写了 YAML 但系统根本没把查询送来」的低级失误。若你更看重多平台一致的编辑体验与可视化排查，Clash Verge Rev 这类围绕 Mihomo 打磨的客户端通常能省下大量反复重启核心的时间；反过来，只提供旧版上游或长期不跟进 Meta 分支的 GUI，常在 Sniffer、DNS 与路由策略上慢半拍，你在 redir-host 下调一整天也未必能达到同样稳定性。
如果你正在选型或升级客户端，可通过本站下载页获取各平台安装包；日常以站内验证过的分发为准，避免不明来源的安装介质带来额外风险。
