Clash Fake-IP 模式详解:DNS 映射原理、fake-ip-filter 与适用场景

先确认 DNS 与流量都经过内核

配置 Fake-IP 前，先确认两件事：应用的 DNS 查询能到达 Clash 内核，应用随后发出的连接也能被同一内核接管。只打开 DNS 设置，却让连接直接走物理网卡，应用可能拿到一个无法在公网访问的合成地址，表现为网页一直等待。

在客户端的配置详情或运行配置中，确认 dns.enable 为 true，dns.enhanced-mode 为 fake-ip。
检查当前是系统代理还是 TUN 接管。系统代理只覆盖遵循代理设置的应用；TUN 可以接管更多 IP 流量，但仍需要正确的路由和 DNS 设置。
打开客户端连接面板，访问一个新域名，观察是否出现域名、命中规则和出口。菜单名称随客户端变化，不要只依据首页的“已连接”状态。
如果使用 Clash Meta（现名 mihomo），以当前内核的有效配置为准。客户端编辑器里的订阅原文，不一定等于合并覆写后的运行配置。

DNS 映射怎样连接到规则分流

从真实解析改为本地映射

传统流程中，应用先问 DNS 获取目标的真实 IP，再向该 IP 建立连接。Fake-IP 则可以先从地址池分配一个合成 IPv4 地址，例如 198.18.0.2，并在内核中保存“域名 ↔ 合成地址”的对应关系。这里的地址只是说明流程，不代表每次查询都会返回同一个值。

应用查询 www.example.com 的 A 记录。
内核记录域名与 Fake-IP 的映射，并向应用返回合成地址。
应用向这个地址发起连接，连接被系统代理或 TUN 等接管路径交给内核。
内核根据目标地址找回域名，用域名规则选择策略组，再由选定出口完成连接。

常见配置中的 198.18.0.1/16 位于 198.18.0.0/15 基准测试保留地址块内，不是目标网站的公网地址。该范围也不是“免费节点地址”。如果企业网络、实验环境或另一套 VPN 正在使用重叠网段，应先处理路由冲突。

为什么可能减少等待

对于能够按域名匹配规则、且代理协议支持传递域名的连接，本地不必先等目标域名的真实 DNS 结果，便可以开始代理连接流程。实际解析可交给远端完成，减少本地 DNS 查询位于关键路径上的机会。

这不等于所有连接都更快。直连出口通常仍需要真实 IP；匹配 IP 类规则时也可能触发解析。节点往返时延、远端 DNS、握手和目标站点响应都可能成为主要耗时。Fake-IP 不能把一个不可用节点变成可用节点，也不会自动降低节点延迟测试的结果。

Fake-IP 与 redir-host 的区别

比较项	fake-ip	redir-host
A 记录应答	对未排除的域名通常返回合成地址。	返回上游解析得到的真实地址。
域名关联	通过 Fake-IP 映射恢复目标域名。	可利用 DNS 缓存等信息关联域名，但真实 IP 可能对应多个域名。
本地解析等待	部分代理连接可推迟或省去本地真实解析。	DNS 应答前通常需要得到真实解析结果。
常见兼容问题	应用检查真实 IP、映射丢失、连接未被接管。	本地解析质量、共享 IP 的域名关联与分流判断。
适用起点	以域名规则分流为主，DNS 与连接路径可控。	应用确实依赖真实 DNS 结果，或兼容性优先。

redir-host 并不等于关闭域名规则，Fake-IP 也不等于完全不查询上游 DNS。内核的连接元数据、DNS 缓存、嗅探设置与规则顺序都会影响最终行为。排查时应看连接面板里的实际域名和命中规则，不要只凭模式名称推断。

如果只有一个游戏或一台 NAS 访问异常，优先排除相关域名，而不是立刻把所有流量切换到 redir-host。如果大量应用依赖真实地址，且无法维护合理的例外范围，再考虑整体切换，并比较相同网络、相同出口下的结果。

fake-ip-filter 配置与边界

在传统 Clash 以及 mihomo 的黑名单过滤语义下，fake-ip-filter 列出的域名不分配 Fake-IP，而是走真实解析。它常被称为“白名单”，更准确的含义是“Fake-IP 排除列表”。这不是代理放行名单，也不决定是否直连。

下面是便于验证的 DNS 配置片段，不是完整订阅。示例使用本机 1053 端口，避免直接占用系统常用的 53 端口；两个公共上游仅用于展示语法，实际应换成当前网络可达、且符合使用需求的解析器。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - 'localhost'
    - '*.lan'
    - '+.home.arpa'
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

listen 只设置监听地址。系统 DNS 不会因为该行配置就自动改用 1053 端口，仍需要客户端或系统完成转发与接管。
ipv6: false 用来简化本例中的 AAAA 应答路径，不是要求所有网络关闭 IPv6，也不代表操作系统的 IPv6 已被禁用。
'*.lan' 针对匹配该模式的局域网子域名；'+.' 形式在支持的域名匹配语法中可覆盖域名自身及子域。单引号也能避免通配符被 YAML 误读。
mihomo 还提供 fake-ip-filter-mode 等扩展。若运行配置设为 whitelist，列表含义会反转；使用前先核对内核支持情况和当前模式，不要把不同模式的配置片段混合。

订阅更新可能替换原文件。长期修改应放在客户端支持的覆写或合并配置中，再检查最终运行配置。特别注意列表合并方式：有的客户端会替换整个过滤列表，而不是追加条目。

哪些域名值得加入排除列表

局域网服务与内部解析域

NAS、打印机管理页、企业内部系统是优先排查对象。例如内部 DNS 将 nas.home.arpa 解析到 192.168.1.20，应用又需要识别这个私有地址时，可以排除该名称，并让内部 DNS 负责解析。若已有正确的内网规则与接管路径，也可能不需要排除，先以实际故障为准。

.local 常与 mDNS 有关。mDNS 使用的组播发现路径不同于普通单播 DNS；加入过滤列表不会自动修复跨网段发现、组播路由或防火墙问题。能用 IP 打开设备页面，但设备发现列表为空时，应同时检查组播与接口选择。

明确检查地址结果的应用

部分游戏、设备绑定工具或网络诊断程序会把 DNS 结果用于地址校验、区域判断或后续协议协商。只有在日志或对照测试确认 Fake-IP 导致异常后，才排除该应用实际查询的域名。一次增加一个域名，重启应用后复测，比复制数百条不明来源的列表更容易定位原因。

不要因为域名属于国内站点就全部排除。直连与代理由规则决定，不由 Fake-IP 地址决定。
不要把整个顶级域加入排除列表作为默认修复。范围过大会改变大量查询的解析路径。
不要把节点服务器域名解析问题一律归结为 Fake-IP。mihomo 中节点域名解析还可能涉及 proxy-server-nameserver 等独立设置。
过滤通常按域名配置，不是把 192.168.1.20 这样的目标 IP 填进去就能修复所有内网访问。

验证 DNS 应答与连接结果

先备份配置，再应用修改。下面的命令直接查询示例监听端口，能把“内核是否回答正确”与“系统是否真的使用它”分开验证。macOS 或 Linux 安装有 dig 时可执行：

dig @127.0.0.1 -p 1053 www.example.com A +short
dig @127.0.0.1 -p 1053 nas.home.arpa A +short

第一条在本例配置下通常应返回 198.18.0.0/16 范围内的地址；具体地址不固定。第二条若已正确接入内部 DNS，应返回内部服务的真实地址。公共解析器返回空结果或不存在域名，并不能证明过滤功能失效。

检查应答。超时先查内核是否监听 127.0.0.1:1053、配置是否加载成功。返回真实公网地址则检查过滤规则及实际增强模式。
检查应用路径。用浏览器访问同一域名，并查看连接面板。直接查询成功只证明测试命令到达内核，不代表浏览器采用了相同 DNS 路径。
检查规则与出口。确认匹配的是预期的域名规则和策略组。能看到域名但连接失败，应继续检查节点、目标端口与远端解析。
记录对照结果。记录修改前后 DNS 应答、连接日志和应用结果，一次只改过滤列表、模式或 DNS 上游中的一项。

不要用 ping 合成地址的结果判断节点可用性。ICMP 与浏览器的 TCP、QUIC 不是同一种连接，TUN 对 ICMP 的处理也可能不同。应优先验证实际业务请求能否完成。

常见故障的排查顺序

切换模式后，部分网站仍打不开

先处理缓存。Windows 可以运行 ipconfig /flushdns 清理系统 DNS 缓存，再完全退出并重启相关应用。浏览器、运行时和应用可能维护独立缓存；清系统缓存不等于清掉所有旧地址。内核重启后映射可能变化，应用若继续使用旧 Fake-IP，也可能失败。

启用 TUN 后，DNS 仍绕过内核

在支持的 mihomo 配置中，TUN 的 dns-hijack 常见目标写法是 any:53。是否生效仍取决于平台、路由和权限。这类设置主要处理传统 DNS 路径，不能直接解密浏览器通过 HTTPS 发出的 DoH 查询。排查时可暂时关闭浏览器自定义的安全 DNS，比较应答与连接日志，之后再决定统一解析方案。

规则写了 DIRECT，内网设备仍不可达

DIRECT 只决定出口，不会自动提供内部 DNS 记录，也不会消除另一套 VPN 的网段冲突。依次检查内部域名能否解析到正确地址、到该地址的系统路由是否正确、TUN 是否接管了不该接管的网段，以及设备端口是否可访问。

怎样决定保留哪一种模式

常规网页访问与域名规则分流，可以从 Fake-IP 开始；局部兼容问题先用精确过滤处理；确实依赖真实 DNS 结果的应用较多时，再对照测试 redir-host。最终判断标准是业务连接、规则命中和解析路径均符合预期，而不是 DNS 返回地址看起来是否像公网 IP。更多接管与规则基础可查阅规则分流使用指南和端口配置说明。