进阶原理 2026-06-25 预计阅读 9 分钟

Clash Fake-IP 模式工作原理:DNS 映射机制与适用场景判断

Fake-IP 是 Clash / mihomo 内核处理 DNS 与 TUN 分流时的关键设计,它用一段保留网段中的虚拟地址暂时替代真实解析结果,让内核提前拿到落地判断依据而不必等待完整的 DNS 往返。本文说明它的映射规则、与 Redir-Host 的差异,以及局域网设备、游戏联机等容易踩坑的场景该如何处理。

DNS 解析在代理链路里卡在哪一步

要理解 Fake-IP 的作用,先看没有它时代理软件要走的完整流程。客户端访问一个域名时,系统先发出 DNS 查询,拿到真实 IP 后再建立 TCP 连接;如果这条连接需要走代理,内核还要根据规则(域名后缀、IP 段、GEOIP 等)决定用哪个代理组转发。问题在于,规则匹配往往需要域名信息,而不是等到拿到 IP 之后才判断——如果 DNS 查询这一步本身也经过代理转发或被劫持,首包建立前就会多出一轮甚至两轮网络往返,尤其在 TUN 模式接管全局流量时,这个延迟会被放大到每一次新连接上。

另一个矛盾点是:很多分流规则写的是域名规则(如 DOMAIN-SUFFIX),但操作系统底层转发的是 IP 层数据包。TUN 模式在网卡层截获流量时,拿到的已经是目标 IP,如果这个 IP 是运营商 DNS 或代理节点自身解析出来的真实地址,内核就丢失了"这个连接原本对应哪个域名"的信息,规则引擎也就没法按域名做判断了。

Fake-IP 的映射机制:用虚拟地址占位

Fake-IP 的思路是把这两个问题一起解决:当客户端发出 DNS 查询时,mihomo 内核不去真实解析,而是从一段保留的私有网段(常见配置是 198.18.0.0/16)里按顺序取一个尚未占用的地址,直接返回给客户端,同时在内存里建立"虚拟 IP ↔ 域名"的映射表。客户端拿到这个假地址后,立刻发起连接,TUN 网卡截获到这个目标 IP,内核查一下映射表就知道真实域名是什么,规则引擎照常按域名匹配、决定走哪个代理节点,真正的域名解析在建立连接的同一时刻由代理节点或内核异步完成,不再单独占用一轮往返时间。

整个过程对客户端是透明的——应用程序不知道自己拿到的是一个假地址,它只管往这个 IP 发包。这也是为什么 Fake-IP 能显著缩短首包时间:DNS 查询这一步几乎变成了本地查表,不再依赖网络延迟。

映射表的生命周期

  • 映射关系存放在内存里,通常带一定 TTL,超过一段时间未使用的条目会被回收复用给新的域名;
  • 同一域名短时间内多次查询会复用同一个虚拟 IP,保证同一会话内地址稳定;
  • 虚拟网段容量有限,长时间运行、访问域名极多的场景下偶尔会出现地址复用导致的短暂映射错乱,重启客户端或清空 DNS 缓存可以解决。

Fake-IP 与 Redir-Host 的行为差异

Redir-Host 是另一种较早的 DNS 处理方式:客户端的 DNS 查询会被直接转发到真实的上游服务器,拿到真实 IP 后返回给客户端,内核再对这个真实 IP 做重定向,靠维护"真实 IP ↔ 域名"的反查表来还原域名信息用于规则匹配。它的好处是客户端手里始终是真实地址,兼容性问题少;缺点是 DNS 查询这一步没有被截断,该有的解析延迟一点没省,而且反查表依赖真实 IP 不重复、不漂移,一旦某个域名背后是 CDN 且频繁换 IP,反查关系就可能过期失效。

对比项Fake-IPRedir-Host
客户端收到的地址虚拟网段内的假地址真实解析地址
DNS 查询耗时近似本地查表,几乎无延迟等待真实上游解析
域名匹配依据内核维护的虚拟 IP 映射表真实 IP 反查表
对 CDN 换 IP 的敏感度不敏感,始终按域名匹配较敏感,反查表可能滞后
兼容性风险部分程序对非常规地址段敏感兼容性较好

简单说,Fake-IP 用"域名匹配 + 假地址占位"换来了速度和对 CDN 场景的稳定性,代价是客户端手里的地址不是真的,极少数会主动检查 IP 合法性或做证书固定(certificate pinning)之外的地址校验的程序可能出现异常。

哪些场景需要回避 Fake-IP 或加白名单

Fake-IP 对绝大多数网页浏览、视频、下载场景没有影响,但以下几类场景需要留意,通常通过 fake-ip-filter 配置项把相关域名排除在 Fake-IP 处理之外,让它们走真实 DNS 解析:

局域网设备与内网服务

访问路由器管理页面、NAS、打印机、公司内网系统等本身解析到局域网地址的域名时,如果被 Fake-IP 接管,客户端拿到的会是假地址,内核再判断该走直连还是代理,这中间任何一步处理不当都可能导致连不上。多数发行版默认已经把常见局域网域名后缀(如 .lan、.local)与内网 IP 段加入过滤名单,自建内网域名建议手动补充。

游戏联机与 P2P 类应用

部分联机游戏、P2P 下载工具、局域网发现协议依赖真实 IP 做对等连接协商,或者对 DNS 返回结果做合法性校验,拿到 198.18.0.0/16 这种保留网段地址时会拒绝连接或匹配失败。这类应用的域名通常需要加入 fake-ip-filter 白名单,或者干脆把整个应用设置为直连,不经过 TUN 网卡处理。

系统级探测与运营商强绑定服务

某些运营商的宽带认证、IoT 设备的云端配对流程会校验解析出的 IP 是否落在特定网段,遇到假地址会判定异常。这类服务出现"能上网但功能异常"的现象时,优先检查是不是被 Fake-IP 影响,再决定是否加白名单。

配置示例与排查思路

以 mihomo 内核为例,DNS 段常见配置结构如下,重点关注 enhanced-mode 与 fake-ip-filter 两项:

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.0/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.stun.*.*"
    - "+.stun.*.*.*"
    - "time.*.com"
    - "*.market.xiaomi.com"
  nameserver:
    - 223.5.5.5
    - 8.8.8.8

排查一个"疑似 Fake-IP 导致异常"的问题时,建议按下面的顺序验证:

  1. 先确认现象是否只在开启 TUN 模式或规则模式下出现,直连模式下正常,基本可以锁定和 DNS 处理方式有关;
  2. 检查内核日志或客户端的连接详情面板,看目标地址是否落在 198.18.0.0/16 这类保留网段内,确认走的是 Fake-IP;
  3. 把对应域名或域名通配模式加入 fake-ip-filter,重启内核或重新应用配置后复测;
  4. 如果域名不固定(比如运营商探测服务经常变更),可以考虑把整个应用或该应用所在的局域网段设为直连,而不是逐条加过滤规则。

什么情况下应该优先选择 Fake-IP

对日常使用而言,Fake-IP 应作为默认选项保留,原因是它对绝大多数流量都能明显降低连接建立的耗时,尤其是在切换节点频繁、访问域名种类多样的使用场景下差异更明显。只有在遇到具体的、可复现的连接异常,并且定位到确实是保留网段地址导致时,才针对那一小部分域名单独处理,而不是整体关闭 Fake-IP 退回到真实解析——那样会让所有连接都重新承担一次完整的 DNS 往返延迟,得不偿失。理解映射机制之后再做取舍,才能既保留速度优势,又不影响个别对地址真实性敏感的服务。

下载 Clash