Fake-IP 模式原理详解:DNS 应答机制、优缺点与 fake-ip-filter 配置

Fake-IP 用保留网段的虚假地址即时应答 DNS 查询,省去解析等待并让域名规则精确命中。本文拆解其工作流程、与 redir-host 的差异、可能踩坑的场景,以及 fake-ip-filter 排除名单的写法。

为什么 DNS 模式会成为一道选择题

普通网络环境里,应用发起请求前先做一次域名解析:系统把域名交给 DNS 服务器,拿到一个真实 IP,再拿着这个 IP 去连接目标服务器。Clash 要做基于域名的分流(比如「某类站点走代理,某类站点直连」),就必须在这一步插一手——问题是,分流规则里写的往往是域名(DOMAIN-SUFFIX、DOMAIN-KEYWORD),而底层网络连接用的是 IP。如果不做特殊处理,规则引擎在连接发生时只能看到一个裸 IP,想反查出它对应哪个域名、该匹配哪条规则,并不总是可靠。

这就是 Clash Meta(mihomo)在 DNS 层提供多种模式的原因,其中最常用的两种是 Fake-IP 和 redir-host(旧称 fake-ip 之外的重定向模式)。二者本质上都在解决同一个问题:如何让「域名规则」在「IP 层连接」发生时依然能对上号。只是走的路线完全不同,带来的行为差异也不小。

Fake-IP 的工作机制

Fake-IP 的思路是:当应用查询某个域名的 DNS 时,Clash 不去真正解析这个域名,而是从一个保留的私有网段(默认常见于 198.18.0.0/16)里挑一个尚未分配的地址,立即返回给应用,同时在内部维护一张「虚假 IP ↔ 真实域名」的映射表。

应用查询 example.com 的 A 记录;
Clash 的 DNS 模块拦截这次查询,分配一个 fake-ip(例如 198.18.0.23),并记录「198.18.0.23 对应 example.com」;
应用拿到 198.18.0.23,发起 TCP/UDP 连接;
连接经过 Clash(无论是系统代理端口还是 TUN 虚拟网卡),Clash 查表还原出原始域名 example.com;
规则引擎用还原出的域名去匹配 DOMAIN 系规则,决定走哪个代理节点;
确认策略后,Clash 再对真实域名发起实际解析(如果目标是直连节点)或直接把域名交给支持 SNI 的代理协议处理,建立真正的出站连接。

整个过程里,应用感知到的是一次「秒回」的 DNS 应答——因为 Fake-IP 根本没有走网络去问权威 DNS 服务器,分配一个本地保留地址几乎零延迟。这也是它相对 redir-host 最直接的优势:DNS 查询延迟几乎为零,同时因为规则匹配阶段拿到的是完整域名而不是 IP,DOMAIN 规则的命中精度也更高。

Fake-IP 与 redir-host 的差异

redir-host 模式走另一条路:Clash 会真的把域名解析成一个可用 IP 返回给应用,但在代理转发阶段,通过读取 HTTP Host 头或 TLS SNI 字段重新识别出域名,再去匹配规则。它的好处是应用拿到的始终是真实 IP,某些强依赖真实 IP 的场景(比如程序自己做 IP 白名单判断)不容易出问题;代价是每次查询都要发起真实解析,DNS 延迟被完整保留,而且对不带明文域名信息的协议(部分 UDP 应用、非标准端口流量)识别能力有限。

对比维度	Fake-IP	redir-host
DNS 应答速度	本地即时生成,几乎无延迟	需要真实解析,延迟随上游 DNS 波动
规则匹配依据	还原出的完整域名	Host / SNI 字段回填
应用拿到的 IP	虚假保留地址	真实 IP
对非 HTTP/TLS 流量识别	不依赖协议特征,识别更稳定	依赖协议里能读到域名,部分场景失效
典型副作用	个别应用做 IP 白名单/证书绑定校验时可能异常	DNS 层延迟叠加,冷启动体验较差

多数 Clash Meta(mihomo)内核的默认发行版都把 Fake-IP 设为默认或推荐模式,尤其是配合 TUN 模式使用时——TUN 接管了系统全部网络层流量,Fake-IP 的域名还原机制能更完整地覆盖各类应用的连接请求,而不只是走系统代理端口的那部分流量。

Fake-IP 容易踩的坑

Fake-IP 不是没有代价,以下几类场景是社区反馈频率较高的问题:

局域网内网服务解析异常:如果 NAS、路由器管理页面、局域网打印机等设备的域名也被 Fake-IP 接管,应用拿到的是虚假地址,一旦这条连接没有经过 Clash(比如直接局域网通信、跳过了代理),连接就会失败。
需要真实 IP 做校验的程序:部分客户端软件会在应用层记录、比对解析到的 IP(常见于某些企业 VPN 客户端、证书绑定校验较严的服务),Fake-IP 返回的虚假地址会让这类校验直接不通过。
基于 IP 的地理位置判断出错:如果某个程序自己拿 DNS 返回的 IP 去做地域判断(而不是走标准的域名连接流程),Fake-IP 的保留网段显然不具备地理信息,判断结果会失真。
与某些 mDNS/局域网发现协议冲突:局域网设备发现依赖真实网段内的地址广播,被 Fake-IP 接管后设备发现可能失效。

这些场景的共同特点是:域名本该走「直连、不受 Clash 分流影响」的通道,但因为落入了 Fake-IP 的默认接管范围而出了问题。解决办法不是关掉 Fake-IP,而是精确地把这些域名从接管范围里排除出去——这正是 fake-ip-filter 存在的意义。

fake-ip-filter 排除名单怎么写

配置项位于 DNS 配置块下,作用是声明一批「即使处于 Fake-IP 模式,也不要伪造应答,直接走真实解析」的域名规则。写法支持通配符,基本结构如下:

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 8.8.8.8
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.market.xiaomi.com"
    - "time.*.com"
    - "ntp.*.com"
    - "*.msftncsi.com"
    - "www.msftconnecttest.com"

几个常用写法要点:

*.lan、*.local 这类通配后缀用于排除局域网设备常见的本地域名后缀;
路由器、NAS 管理面板如果用的是固定域名(比如厂商分配的 DDNS 域名),建议单独加一行精确排除;
系统级联网检测域名(如 Windows 的 msftncsi.com、msftconnecttest.com)保持真实解析,避免系统误判「无网络连接」;
时间同步(NTP)相关域名建议排除,部分客户端对时间同步的响应延迟敏感;
如果某个特定 App 的登录/校验域名在使用中反复出现连接异常,可以先把它单独加进 filter 试一次,再判断问题是否消失。

注意顺序与来源

不同 Clash Meta(mihomo)前端(Clash Verge、Clash for Windows 衍生版、CFW 等)对配置文件的合并策略不完全一致,如果使用的是订阅生成的配置,自定义的 fake-ip-filter 可能在订阅更新后被覆盖。建议把常用的排除项写进本地覆写(override)配置,而不是直接改订阅生成的原始文件。

什么情况该切回 redir-host 或直接关闭 Fake-IP

Fake-IP 对绝大多数使用场景是合适的默认选择,尤其是配合规则分流、TUN 模式使用时体验更连贯。但如果遇到以下情况,可以考虑切换或调整:

整个网络环境高度依赖局域网内多设备的域名互通(家庭 NAS 集群、自建局域网服务较多),排除名单维护成本已经高于收益;
使用的客户端软件明确要求「拿到的 DNS 结果必须是真实公网 IP」,且该软件无法容忍 Fake-IP 网段;
只需要非常基础的分流能力,对 DNS 延迟不敏感,更看重「所见即所得」的真实 IP 排查体验(方便用 ping、nslookup 之类工具直接核对)。

切换方式很简单,把 enhanced-mode 从 fake-ip 改成 redir-host 即可,不需要改动规则集本身,因为 DOMAIN 系规则在两种模式下都能正常工作,差别只在底层的应答机制。

排查思路小结

遇到「某个域名连不上,但直连正常、代理规则看起来也没问题」的情况,可以按下面顺序排查:

确认当前 DNS 模式(查看配置文件 enhanced-mode 字段,或客户端界面里的 DNS 设置);
如果是 Fake-IP 模式,检查该域名或其所在网段是否本应走局域网直连,却未加入 fake-ip-filter;
查看客户端日志或连接面板,确认这条连接的目标 IP 是否落在 fake-ip-range 声明的网段内(默认多为 198.18.0.0/16);
临时把可疑域名加入 fake-ip-filter 后重启内核测试,问题是否消失;
仍未解决时,尝试将 enhanced-mode 临时切到 redir-host 做对照测试,缩小问题范围。

理解 Fake-IP 的应答机制之后,大多数「DNS 相关的连接异常」都能归结为「该域名要不要走 Fake-IP 接管」这一个问题,排查路径会比一开始想象的清晰很多。