Clash Meta：fake-ip 与 redir-host 怎么选？DNS 与分流对齐实战（2026）

1. 为什么故障长得像“规则坏掉”：DNS 与规则各自看到什么

Clash Meta 的规则（DOMAIN、DOMAIN-SUFFIX、GEOIP 等）本质上是在连线建立前后，尽力替你决定“这一笔流量要进哪个策略组”。但应用程序与操作系统往往先做一次 名称解析：解析走谁（ISP、公共 DNS、浏览器 DoH、或 Clash 内建 DNS）会直接影响“你看到的主机名／IP”与“核心实际用来比对规则的线索”是否一致。

在 fake-ip 模式下，客户端常先拿到一个本机池的临时位址，真正的解析与出口决策延后到连线阶段再做；好处是依域名拆流通常比较直觉。相对地，若你同时开着浏览器安全 DNS、系统加密 DNS或订阅里另一套 dns: 片段，资讯就容易分裂成“表面上解析成功，规则却对不到你想像的那条”。这也是为什么我们会建议在调 mihomo 前先读 Windows 上关闭浏览器安全 DNS 并校准系统代理：先把场外选手请出擂台，比较不会误判成“规则集写错”。

redir-host（或你惯称的 redir-host 类行为）则较偏向让解析结果更贴近传统“先解析、再连线”的模型：应用程序看到的 IP 往往就是（或更接近）上游解析器回来的答案，规则若高度依赖 GEOIP 或 实际位址所属区域，行为会与 fake-ip 时期截然不同。两者没有绝对优劣，只有与你的规则风格、客户端是否绕过本机 DNS、以及是否启用 Sniffer 的组合是否合拍。

2. fake-ip 与 redir-host：行为差异与适用情境

下面用“使用者在乎的结果”来谈取舍，而非逐行搬源代码术语。写设定时请以你实际使用的 Clash Meta 核心版本与 GUI 显示名称为准，本节描述的是社群设定里最常遇到的两种故事线。

• fake-ip：有利于把“同一个网域家族”集中丢进指定策略组，对大量使用 DOMAIN-SUFFIX、订阅规则集的使用者较友善；但若 fake-ip-filter 漏写、或应用程序硬要自解释名称，就可能出现“规则上看到 A、连线实际走 B”的错觉。
• redir-host：对“必须先知道真实目的地位址”的旧客户端或某些凭 IP 判区的服务，有时比较不易踩雷；代价是你对 nameserver 品质与DNS 泄漏要更有意识——上游回错答案，后面整条分流都会跟着歪。

若你正在处理“订阅更新 SSL 错误、特定 API 主机 TLS 握手怪异”这类议题，可以先对照 Windows 订阅更新与 TLS／DNS 日志：那条路径和“网页浏览”不完全相同，但同样需要 dns: 区块与 nameserver-policy 各司其职，而不是只靠换节点。

3. 分流失效对照：症状、常见成因、先查哪一段设定

以下整理实务上最常收到的回报，刻意用“可观测现象”写，方便你对照自己的 mihomo 日志与客户端画面。

若你关心的是“特定云服务／AI 站台”如何把网域与 DNS 写进同一份专题，亦可交叉阅读 Claude 与 Fake-IP DNS：该文以单一平台示范“名称解析与规则必须同一批次检查”的方法论，与本篇一般化框架互补。

4. YAML 骨架：dns 区块与 enhanced-mode 实务注意点

实际键名请以你的设定为准；下面是教学用骨架，注解一律使用英文以利版本控管。重点在于：enable、enhanced-mode、nameserver、fallback、nameserver-policy 必须成套思考，而不是只改一行就期待奇迹。

dns:
  enable: true
  listen: 0.0.0.0:1053  # example; align with your OS resolver / forwarding
  enhanced-mode: fake-ip  # or redir-host — pick one story per debugging session
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - tls://1.1.1.1
  fallback:
    - https://dns.cloudflare.com/dns-query
  # Route sensitive domains away from polluted paths:
  nameserver-policy:
    'geosite:cn':
      - https://doh.pub/dns-query

5. mihomo 日志怎么读：把“主机名／IP／策略”对回同一笔连线

分步排查时，请强迫自己回答三个问题：① 客户端以为自己在连哪个 主机名？② 核心在规则匹配时手上有什么线索（域名、位址、行程）？③ 最后被送进哪个策略组与节点？三者对不起来，就不要先换节点。

实务上可以从“重现问题的单一网域”开始：先在 GUI 或外部 API 面板把日志级别调到能看见规则命中，再对照浏览器 Network 里的 Host。若你发现日志里出现的主机名与规则表达式永远差一个子域，通常要先改规则表达式或规则顺序，而不是改 DNS 模式；反之，若命中策略正确、但连线仍行为怪异，再回头改 dns: 或考虑 Sniffer。

想从头建立“规则优先序”直觉，可读 高级规则分流指南，把“远端规则 provider 合并后实际顺序”画在纸上；当列表一排开，你会更容易看出是谁提早把流量喂进 MATCH。

6. 修复步骤：可重现的操作顺序（含切模式与清快取）

请把下列步骤当成实验清单，而不是“每一步都做了就一定能好”的咒语；目的是在最少变因下定位问题层级。

1. 冻结变因：同一组规则、同一颗节点、同一个浏览器分页，只改 DNS 故事，避免“同时改规则又改节点”。
2. 关掉场外解析：暂时关闭浏览器 DoH、操作系统加密 DNS，与其他本机 AdGuard／安全软件内建解析拦截；必要时参考前述 Windows 浏览器篇。
3. 单一路径验证：在 fake-ip 与 redir-host 之间做一次有计划的切换，每次都重新载入核心、清快取，观察日志差异而不是只看网页表象。
4. 校对 fake-ip 例外：若坚持 fake-ip，检查 fake-ip-filter 是否涵盖了必须看真实位址的网段或网域（例如部分内网或特定套餐要求）。
5. 校对 nameserver-policy：确认“国内／国外”或“污染敏感”网域没有被错配到会回传意外答案的上游。
6. 引入 Sniffer 之前先写假说：若怀疑 HTTPS／QUIC 客户端带的主机资讯与网域规则脱钩，再开启 Sniffer 相关段落，并用专文对照参数语意，避免一次开太多外挂式功能让变因爆炸。

完成后请把“最后一份可行组合”记录下来：包含 enhanced-mode、是否启用 Sniffer、关键网域走哪个 nameserver-policy。日后订阅范本更新时，你才能迅速 diff 出是谁又塞了一行覆写。

7. 与 Sniffer／SNI 的衔接（上下篇分工）

当你发现“规则写的是网域 A、TLS 交握里却是别的主机别称或 CDN 边缘”时，单靠改 fake-ip／redir-host 可能仍不足；此时需要的是把连线层观测到的名称与规则对齐。这正是 Clash Meta Sniffer 与 HTTPS／SNI 日志那篇的战场：本篇刻意停在“DNS 模式与解析路径”层级，把 Sniffer 当成下一层工具链，避免两篇互相复制同一长段截图。

若你的主要痛点是“服务商看 IP 判区”或“固定节点需求”，请回到平台专题文；本篇只负责让你在开启那些进阶选项之前，先确认 DNS 模式没有让规则形同虚设。