Clash Fake-IP 与 Redir-Host：本地 DNS 解析失败排查

先搞清：两种模式分别在解决什么问题

在 Clash（含 Meta / mihomo 系）里，DNS 不只是「把域名变成 IP」这么简单。开启 dns.enable 与增强模式后，内核会介入应用的解析流程，以便后续按域名做规则匹配、减少泄露、并在部分场景下提前决定流量走向。你看到的 fake-ip 与 redir-host，描述的是增强模式如何对待「域名 → 地址」这一步，而不是两个完全无关的功能开关。

Fake-IP 的思路是：对多数域名，内核先返回一段虚拟地址（常见为 198.18.0.0/15 一类保留段），让连接尽快建立到 Clash；当真正需要向外发起连接时，再结合规则与远程解析拿到真实 IP。优点是规则可按域名尽早介入、对部分应用更「顺滑」；代价是如果某些域名必须依赖本机或局域网 DNS 的真实结果（例如 .local、路由器后台、NAS、打印机、公司域控下发的内网记录），虚拟地址可能让你感觉「解析对了却连不上」或「浏览器一直转圈」。

Redir-Host（及与之接近的行为）则更偏向：在增强流程里尽量保留「解析结果与真实地址一致」的路径，让依赖真实 IP 的应用行为更接近未接管 DNS 时。优点是本地与内网场景往往更直观；但在复杂规则、DoH 与缓存叠加时，有时需要更仔细地对齐 nameserver、fallback 与 nameserver-policy，否则仍会出现「解析慢」「偶发污染」等现象。

记忆锚点 若你的痛点是内网与本地域名，先不要急着全局改模式，优先看 fake-ip-filter 与直连规则是否覆盖这些域名；若痛点是规则命中与分流一致性，fake-ip 往往更顺手。

怎么选：用场景表快速对齐

下面这张表不是绝对标准，但能帮你在几分钟内缩小方向。实际以你所用的内核版本、是否 TUN 以及订阅是否自带 dns 段覆写为准；若你使用 TUN 或系统级透明代理，可与我们的TUN 与系统代理对照排查教程一起阅读，避免把纯 DNS 问题误判成路由或权限问题。

你的主要场景	更常优先考虑	备注
大量分流规则依赖域名命中，追求一致性与延迟体验	fake-ip	配合可靠的 nameserver 与 fallback；注意过滤本地域名
频繁访问路由器管理地址、NAS、打印机、`*.local` 等	redir-host，或 fake-ip + 完善 fake-ip-filter	核心是「这些域名不要走虚拟地址」
公司 VPN、零信任客户端与 Clash 同时存在	谨慎测试两种模式 + 严格分流	避免 DNS 与隧道顺序互相打架
部分国内站「只有这台电脑打不开」	先查解析是否异常，再谈模式	可能是污染、IPv6、DoH 与系统 DNS 叠加

如果你刚升级过内核或换了客户端分支，也建议对照Meta 内核升级教程确认 DNS 相关字段是否仍被旧配置覆盖，避免「界面里改了、实际运行的配置没改」的假成功。

本地域名与内网：fake-ip-filter 与直连规则

在 fake-ip 下，绝大多数用户的局域网解析失败并不是模式本身「坏了」，而是需要走真实解析的域名没有被排除在虚拟地址机制之外。Clash 提供 fake-ip-filter（或等价配置项，具体名称随内核与版本略有差异）用于声明：这些域名请不要使用 fake-ip 响应，而应走正常的解析路径。

实践中建议至少覆盖：纯局域网主机名、路由器与网关常见域名、组播与本地发现相关后缀、以及你明确知道必须解析到内网段的服务。若你使用公司内网域名，请向 IT 文档核对应使用的内网 DNS，并通过 nameserver-policy 让这些后缀走指定解析器，而不是与公网 DNS 混在一锅里。

与此同时，规则层要确保上述流量在期望时命中 DIRECT。仅有正确的 IP 却仍将数据包送进代理出口，仍会表现为「网页空白」「证书报错」或「连接超时」。关于规则顺序与策略组设计，可结合YAML 规则分流指南中的思路，把「内网与大陆常用域名」从全局代理里拆出来，减少误伤。

常见误区 把 redir-host 当成「万能药」却不整理 nameserver，可能只是把问题从 fake-ip 挪到了「解析源不可靠」上，症状仍是打不开或偶发劫持。

症状对照：先判断是「解析」还是「连接」

排查时建议先分清失败发生在哪一阶段。解析阶段典型表现包括：浏览器提示找不到服务器、ping 显示未知主机、Clash 日志里出现 DNS 超时或 NXDOMAIN。连接阶段则往往是：域名能解析，但 TCP 握手慢、TLS 失败、或特定端口不通。若你在移动端也遇到「全部节点超时」类现象，可与Android 端 DNS 与超时排查文对照，因为手机侧还有分应用、私人 DNS 等额外变量。

对于「只有部分国内站异常」，要特别留意是否启用了仅海外可用的 DoH、系统是否优先 IPv6、以及运营商对特定域名的缓存策略。此类问题有时与 Clash Fake-IP 无直接关系，但在 fake-ip 下更容易被误认为是「模式选错」，因为应用层报错都笼统地显示为「无法访问」。

推荐排查顺序：从外到内、一次只改一项

下面步骤按成本低 → 成本高排列。每完成一步就复测目标网站或内网地址，避免同时修改 DNS 模式、规则与系统设置导致无法归因。

确认当前生效配置：在客户端中查看运行中配置与本地覆写，核对 dns 段是否来自订阅、是否被 profile 合并覆盖。
检查系统 DNS 与私人 DNS：暂时关闭 Android 私人 DNS 或改为自动，在桌面端避免与 Clash 重复指定冲突的 DoH。
针对内网域名配置 fake-ip-filter：在保持 fake-ip 的前提下加入后缀或完整域名，观察是否立即恢复访问。
切换 redir-host 做对比实验：仅作为 A/B 测试，记录差异；若仅在 redir-host 下正常，说明问题集中在 fake-ip 与本地解析的交集。
精简 nameserver 与 fallback：确保国内域名与国内 DNS、敏感域名与可信 DNS 的映射合理，必要时用 nameserver-policy 分域。
对照规则与日志：查看目标域名是否被错误代理、是否存在 GEOIP 或 RULE-SET 顺序导致的误命中。

若你使用命令行或无 GUI 的 Meta 实例，还可提高日志级别，观察 DNS 查询与规则匹配的先后顺序；这与 headless 部署里的 systemd 日志思路一致，重在「把时间线串起来」而非死记某个开关。

配置片段示例（理解用，请按环境改写）

下列 YAML 仅用于说明字段之间的相对关系，不同客户端可能对字段名与默认值有细微差别，请以你所用内核文档为准。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.stun.*"
  nameserver:
    - 223.5.5.5
  fallback:
    - "https://1.1.1.1/dns-query"
  nameserver-policy:
    "geosite:cn": 223.5.5.5

当你改为 redir-host 时，仍应保留清晰的 nameserver 与污染应对策略，而不是删除整个 dns 段。许多「网页打不开」的根因是解析源而非增强模式标签本身。

小结：模式是手段，解析链路与规则才是主线

Clash DNS 模式的选择，本质是权衡「域名规则介入时机」与「本地真实解析需求」。Fake-IP 并不必然导致内网不可用；Redir-Host 也不保证一劳永逸。遇到本地域名与解析失败时，优先用 fake-ip-filter 与 nameserver-policy 把异常域名从错误路径上摘出来，再用日志确认是 DNS 还是规则层的问题，通常比反复切换模式更有效。

相比在论坛里零散搜答案，把上述步骤固化成你自己的检查表，能显著减少试错时间。Clash 在稳定性与可维护性上仍适合作为长期主力方案——尤其在需要同时处理分流、内核更新与多设备场景时，一份结构清晰的配置比临时补丁更省心。

若你希望在一处完成各系统客户端的获取与版本管理，可从本站下载中心选用适配当前平台的 Clash 客户端，再按本文思路整理 DNS 与规则，整体体验会更连贯。

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

更多专题可继续浏览技术专栏中的规则分流与客户端排查文章，把 DNS、TUN 与策略组串成一套可复用的知识体系。