Clash Fake-IP 模式原理详解:与 Redir-Host 的区别及适用场景

DNS 解析在代理链路里扮演什么角色

在讨论 Fake-IP 之前,有必要先厘清一个容易被忽略的问题:客户端在访问一个域名时,究竟是先解析出真实 IP,再决定走哪条路径,还是反过来?这个先后顺序直接决定了代理软件的分流准确度与响应速度。传统操作系统的网络栈遵循的是"先解析、再连接"的顺序——应用程序调用系统的 DNS 解析函数得到一个真实 IP,再用这个 IP 发起 TCP 或 UDP 连接。如果代理软件也照搬这个顺序,就会遇到一个尴尬的局面:域名解析这一步往往还没经过代理,直接暴露给了本地网络的 DNS 服务器,而后续的连接却要走代理规则做分流判断。

Clash 内核(包括 Clash Premium 与 Clash Meta/mihomo)在设计规则匹配时,大量规则类型都是基于域名的,例如 DOMAIN-SUFFIX、DOMAIN-KEYWORD。这类规则在连接发起阶段就能完成匹配,不依赖 IP。但也有一部分规则依赖 IP,例如 GEOIP、IP-CIDR,这类规则要求客户端在做分流决策前,必须先拿到一个可用的 IP 地址。矛盾由此产生:如果照常规流程先做真实 DNS 解析,解析请求本身可能已经泄露到本地网络运营商或局域网的 DNS 服务器,这就是所谓的 DNS 泄露;而如果完全不做解析就把域名交给远端代理节点处理,又会让本地基于 IP 的规则失效。Fake-IP 正是为了在这两者之间找到一个折中方案而设计的机制。

Fake-IP 如何用虚假地址换取速度与隐私

Fake-IP 的核心思路可以用一句话概括:客户端在本地维护一个"域名到虚假 IP"的映射表,当应用程序请求解析某个域名时,Clash 内核不去真正查询公共 DNS,而是从一个保留的私有网段(通常是 198.18.0.0/16)里分配一个从未使用过的地址,直接返回给应用程序。应用程序拿到这个看似正常的 IP 后,照常发起连接,数据包被本地路由或 TUN 网卡截获,内核再根据这个虚假 IP 反查出对应的原始域名,把域名交给远端代理节点去做真正的 DNS 解析与连接。

这套流程带来的第一个好处是速度。因为应用程序拿到虚假 IP 几乎是零延迟的本地操作,不需要等待任何真实网络往返,首包建立的等待时间被大幅压缩。第二个好处是隐私:本地网络环境完全看不到用户实际访问的域名对应的真实 IP 是什么,DNS 查询请求也没有真正发往本地网络的解析服务器,从而减少了 DNS 层面的信息暴露。第三个好处是规则兼容性:由于每个虚假 IP 都能唯一映射回原始域名,基于域名的规则可以照常在本地完成匹配,而不必等待远端解析结果。

典型的 Fake-IP DNS 配置结构大致如下(以 mihomo 内核为例):

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'time.*.com'
    - 'ntp.*.com'
    - '+.push.apple.com'
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query

其中 enhanced-mode: fake-ip 明确指定启用 Fake-IP 增强解析模式,fake-ip-range 划定了虚假地址池的网段范围,而 fake-ip-filter 则是决定哪些域名不走 Fake-IP、直接使用真实解析结果的关键配置项,后文会专门展开说明它的必要性。

Fake-IP 与 Redir-Host 的本质差异

在 Fake-IP 出现之前,Clash 生态里更早被广泛使用的是 Redir-Host 模式,二者都属于"增强 DNS 模式"(enhanced-mode)的取值选项,但工作方式完全不同,理解这个差异有助于判断该在什么场景下用哪一种。

• Redir-Host 的做法:客户端在收到 DNS 请求后,会真实地向上游服务器发起解析,拿到域名对应的真实 IP,再把这个真实 IP 直接返回给应用程序。规则匹配主要依赖后续流量重定向阶段对域名的记录做判断,连接建立时使用的是真实 IP。
• Fake-IP 的做法:如前文所述,不做真实解析,直接返回一个虚假地址,真实解析被推迟到连接真正建立、流量进入代理节点之后才在远端完成。

这个差异带来几个可以感知的实际区别。首先是速度:Redir-Host 每次解析都要等待一次真实的 DNS 往返,而 Fake-IP 省去了这一步,首次建连速度更快,尤其在跨境网络环境下体感差异明显。其次是隐私边界:Redir-Host 模式下,本机依然会把真实域名交给上游 DNS 服务器解析,即使这个上游是可信的加密 DNS,解析记录也会经过本地网络出口;Fake-IP 则把解析这一步完全挪到了代理节点之后,本地网络看不到任何真实域名对应的解析行为。第三是兼容性:一些依赖"应用层直接拿到真实 IP"的场景(例如某些游戏客户端会把服务器 IP 用于连接质量检测、或是某些内网穿透工具需要真实地址做校验)在 Fake-IP 下可能出现异常,因为应用程序拿到的始终是一个虚假地址,而 Redir-Host 至少能保证应用层看到的 IP 是真实的。

因此,现阶段主流客户端(包括基于 mihomo 内核的各类 GUI 客户端)默认推荐使用 Fake-IP,把 Redir-Host 保留为兼容性问题的备选方案,而不是反过来。如果你在使用中发现某个应用出现连接异常、地址显示错乱或握手失败,先检查是否是 Fake-IP 机制导致的真实 IP 不可见问题,再考虑临时切换到 Redir-Host 做排查。

为什么必须正确配置 fake-ip-filter

Fake-IP 虽然带来了速度与隐私的双重收益,但也不是对所有域名都适用。有一类域名场景下,应用程序确实需要拿到真实 IP 才能正常工作,这时就必须把它们加入 fake-ip-filter 名单,让这些域名跳过 Fake-IP 逻辑,走真实解析。

局域网与内网服务

如果家里或公司内网有通过域名访问的 NAS、路由器管理页面、内网穿透服务等,这些域名解析出的应该是局域网内的真实 IP,而不是一个虚假地址——否则设备将无法定位到内网中的实际主机。常见做法是把 *.lan、*.local 以及自定义的内网域名后缀统一加入过滤名单。部分企业内网还会使用自建域名解析到私有网段,这类域名也应当归入过滤范围。

时间同步与低延迟检测服务

操作系统的时间同步协议(NTP)通常直接使用 IP 通信而非依赖代理转发,如果被 Fake-IP 接管,反而会导致时间同步失败或延迟异常。类似的还有部分系统级的网络质量检测服务,这些请求本身不需要经过代理,也不适合被虚假地址干扰,因此常见配置模板里会预置 ntp.*.com、time.*.com 这类规则。

推送服务与实时通信

一些操作系统级别的推送通道(例如设备与厂商推送服务器之间维持的长连接)对连接稳定性和真实地址有较高要求,如果被 Fake-IP 接管可能出现推送延迟或断连,配置模板中常见的 +.push.apple.com 一类通配规则就是为了避免这种情况。

游戏平台与实时对战服务

部分网络游戏客户端会在连接服务器前对目标 IP 做主动的网络质量探测,或者在游戏内显示服务器的真实延迟与地址信息,这类场景下如果应用层拿到的是虚假 IP,探测结果会失真,甚至触发游戏客户端自身的异常连接判定。对于经常出现连接异常、匹配失败的游戏平台域名,建议先尝试将其加入 fake-ip-filter,观察问题是否消失,再决定是否需要单独为该游戏建立分流规则。

实际使用中常见的疑惑与排查思路

启用 Fake-IP 之后,一些用户会在使用体验里遇到看似奇怪的现象,这里列出几种典型情况以及对应的排查方向。

为什么某些应用显示的服务器 IP 是 198.18 开头的陌生地址

这正是 Fake-IP 网段在起作用——只要看到形如 198.18.x.x 的地址出现在应用程序的连接信息里,通常就说明这个连接被 Fake-IP 接管了,域名解析结果是虚假地址而非真实 IP。这本身是正常现象,不代表配置出错,除非该应用因此出现功能异常。

切换网络后地址映射是否需要清理

Fake-IP 的映射表是在客户端本地维护的,通常会随进程重启或手动清空 DNS 缓存而重置。如果切换了网络环境后出现连接异常,可以尝试在客户端界面里查找"清空 Fake-IP 缓存"或类似选项,部分 GUI 客户端会把这个操作放在 DNS 设置或高级设置分区里。

IPv6 环境下要注意什么

Fake-IP 默认场景下主要覆盖 IPv4 地址池,如果本地网络同时启用了 IPv6 且系统优先尝试 IPv6 连接,可能出现部分流量绕过 Fake-IP 逻辑直接发起 IPv6 连接的情况。多数配置模板会显式将 DNS 配置中的 ipv6 项设为 false,或者配合规则集单独处理 IPv6 流量,避免出现绕过代理判断的连接路径。

如何验证 DNS 泄露是否得到改善

可以借助支持查看 DNS 解析来源的在线检测工具,在开启 Fake-IP 前后分别检测一次,对比解析记录归属地是否发生变化。正常情况下,启用 Fake-IP 并配合远端可信 DNS 解析后,检测结果应显示解析行为发生在代理节点所在网络,而不是本地网络运营商的 DNS 服务器。

Fake-IP 与 TUN 模式的配合关系

Fake-IP 常常与 TUN 模式一起被提及,但两者解决的是不同层面的问题,不要混为一谈。TUN 模式是在系统网络层建立一张虚拟网卡,让所有出站流量(不只是浏览器或个别应用)都经过 Clash 内核处理,解决的是"哪些流量能被纳入代理"的覆盖面问题;而 Fake-IP 解决的是"域名解析这一步该怎么处理"的问题,二者可以独立开启,也可以同时使用。实际配置中,启用 TUN 模式后往往会同步建议开启 Fake-IP,因为这样才能确保 TUN 网卡截获的流量在域名规则匹配阶段拿到足够信息,同时避免系统级 DNS 请求绕过虚拟网卡直接发往本地网络,形成完整的闭环。

如果只开启 TUN 模式而 DNS 增强模式设置为空或使用系统默认解析,依然可能出现 DNS 请求绕过代理直接发往本机配置的 DNS 服务器的情况,这也是排查"TUN 模式开了但还是提示解析失败/DNS 泄露"问题时最先应该检查的配置项。

配置建议小结

综合以上原理,给出几条可以直接落地的建议:普通用户在没有特殊内网需求的情况下,保持客户端默认的 Fake-IP 配置即可,不需要额外调整;有内网服务、企业域名解析需求的用户,应主动检查并补充 fake-ip-filter 名单,把内网域名后缀加入其中;游戏与实时通信类应用出现连接异常时,优先怀疑 Fake-IP 影响,通过临时过滤对应域名或切换到 Redir-Host 做对比测试来定位问题;开启 TUN 模式的用户,应确认 DNS 增强模式与 Fake-IP 网段配置已经同步生效,避免出现流量被截获但解析仍走本机默认 DNS 的半截配置状态。