进阶技巧 · 预计阅读 8 分钟

Fake-IP 模式是什么:DNS 劫持原理、优缺点与适用场景分析

从 DNS 解析流程讲清 Fake-IP 模式的工作原理:为什么返回保留段假地址、如何减少解析延迟,以及局域网服务、游戏联机等场景下需要配置 fake-ip-filter 的原因。

为什么代理软件要插手 DNS 解析

正常上网时,设备访问一个域名要先经过一次 DNS 解析:系统把域名交给 DNS 服务器,拿到一个真实 IP,再用这个 IP 建立连接。问题在于,Clash 这类基于规则做分流的代理工具,很多分流策略是按域名匹配的——比如按 GeoSite 规则判断某个域名该走代理还是直连。如果代理软件对 DNS 解析完全不插手,只在收到连接请求时看到一个裸 IP,就没法反查出这个 IP 对应的域名,规则里写的域名匹配条件也就形同虚设。

为了解决这个问题,Clash/mihomo 内核提供了几种 DNS 处理模式,Fake-IP 是其中默认且最常用的一种。它的思路简单直接:客户端查询域名时,不把真实 IP 交给应用,而是返回一个内核自己编造的、外界从未真正分配过的假地址,同时在内核内部记住这个假地址对应哪个域名。等应用真正发起连接时,内核再用记住的域名做规则匹配,该走代理就走代理,该直连就直连,整个过程对上层应用完全透明。

Fake-IP 模式的工作原理:保留地址段与映射表

Fake-IP 返回的地址并不是随机瞎编的,而是从一段专门划出来、不会被任何真实网络路由到的私有地址段里分配,常见配置里默认使用 198.18.0.0/16 这类保留段。这段地址在公网上不会被实际使用,内核把它当作"临时门牌号"来用,具体流程大致是这样:

  1. 应用发起 DNS 查询,请求解析某个域名;
  2. Clash/mihomo 的 DNS 模块拦截这次查询,不去问真实的上游 DNS 服务器要地址,而是从保留地址池里取一个尚未使用的假 IP;
  3. 内核在内存里维护一张映射表,记下"假 IP ↔ 域名"的对应关系,并把这个假 IP 返回给应用;
  4. 应用拿着假 IP 发起连接,内核在连接建立阶段查表,还原出真实域名,再按规则集判断走哪条策略、走哪个代理节点;
  5. 如果规则判定要走代理,内核直接把域名交给代理节点侧去解析和连接,真实 IP 解析这一步被推迟到了链路的另一端。

这套机制带来的直接好处是解析延迟明显降低——因为大多数情况下内核根本不需要真的去问一次上游 DNS,只是从本地地址池里发一个假地址,响应几乎是瞬时的。同时因为域名信息全程保留在内核里,基于域名的分流规则可以精确生效,不会退化成"只能按 IP 段猜测"的粗糙匹配。

要点Fake-IP 返回的地址只在本机代理进程内部有意义,一旦离开这台设备(比如被其他程序记录、转发给别的机器),这个假地址就毫无用处,因为它从未被真正分配和路由。

Fake-IP、Redir-Host 与正常解析模式的取舍

除了 Fake-IP,内核通常还支持另外两类 DNS 处理方式,理解它们的差异有助于判断自己的场景该选哪个:

  • Fake-IP 模式:如上所述,返回假地址,内核内部按域名做规则匹配。优点是延迟低、域名匹配精确;缺点是假地址不能直接用于需要真实 IP 的场景,比如某些应用会把解析到的 IP 缓存下来做健康检查或直接展示。
  • Redir-Host 模式:同样依赖返回给应用的地址来触发规则判断,但更偏向按目标端口做重定向转发,实现细节和适用范围比 Fake-IP 更受限,目前主流客户端已较少将其作为默认选项。
  • 正常解析(Fake-IP 之外的直接解析)模式:每次都向真实的上游 DNS 服务器发起查询,拿到真实 IP。优点是应用拿到的始终是可用的真实地址,兼容性最好;缺点是失去了基于域名的精确规则匹配能力(只能按 IP 段判断),而且每次查询都有真实的网络往返延迟。

对绝大多数日常使用场景——网页浏览、视频、社交应用——Fake-IP 都是延迟更低、匹配更准的选择,这也是为什么它被大多数客户端设为默认模式。

局域网服务与游戏联机为什么必须配置 fake-ip-filter

Fake-IP 的假地址机制在跨设备场景下会暴露出明显短板。典型情况有两类:

局域网内的自建服务或路由器管理页面。 假设家里有一台 NAS 或路由器,域名解析走的是内网 DNS,正常情况下应该拿到一个 192.168.x.x 之类的内网真实地址。但如果这类域名没有被排除在 Fake-IP 处理之外,内核会照样返回一个 198.18.x.x 假地址,应用拿着假地址去连接,内核尝试按规则匹配转发,结果往往是连不上,或者绕了一圈才连上,体验上表现为"内网设备访问变慢甚至超时"。

游戏联机与实时对战类应用。 不少游戏客户端会把服务器域名解析结果直接用于建立 UDP 连接、做延迟探测,甚至在界面上把解析到的 IP 展示给用户做节点选择依据。假地址在这类场景下会导致连接失败、延迟数值异常,或者游戏内的服务器列表根本无法正确加载。

解决办法是在 DNS 配置里加入 fake-ip-filter 字段,把这些特定域名或域名模式排除在 Fake-IP 处理范围之外,让它们走真实解析。常见配置示例:

dns:
  enable: true
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "192.168.*.*.*"
    - "router.asus.com"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"

其中 *.lan、*.local 一类通配写法覆盖了大多数家用局域网设备常用的域名后缀;带 +. 前缀的写法表示同时匹配主域名及其所有子域名,常用于排除连通性检测一类系统级域名,避免它们被假地址干扰导致系统误判"网络不可用"。游戏相关域名建议逐条添加官方文档给出的服务器域名列表,而不是笼统排除整个大类,否则会牺牲掉 Fake-IP 本该带来的分流精度。

排查思路:遇到"某个服务连不上"时怎么定位

当怀疑问题出在 Fake-IP 身上时,可以按下面的顺序排查:

  1. 先确认当前 DNS 模式确实是 Fake-IP,而不是其他模式导致的问题;
  2. 查看客户端的连接日志或域名解析记录,确认目标域名解析出来的是不是 198.18.x.x 或类似保留段地址;
  3. 如果是,说明该域名被错误地纳入了 Fake-IP 处理,需要把它加入 fake-ip-filter;
  4. 修改配置后重启内核或重新加载配置(不同客户端操作入口不同,一般在配置管理页面有"重新加载"按钮),避免旧的映射表继续生效;
  5. 如果问题依旧,再检查是否是规则集本身把该域名分流到了不可用的代理节点,而不是 DNS 模式的问题。
注意修改 fake-ip-filter 后,已经建立的映射关系可能还留在缓存里,建议重启代理内核而不是只重新加载配置文件,确保旧的假地址映射被清空。

什么情况下可以考虑关闭 Fake-IP

并不是所有场景都必须用 Fake-IP。如果所在网络环境里大量应用依赖真实 IP 做校验、或者局域网服务特别多、逐条添加过滤规则维护成本过高,也可以整体切换回真实解析模式,牺牲一部分延迟优势换取更少的兼容性问题。不过对大多数只是想让浏览器、社交应用、视频客户端正常分流的用户来说,保留 Fake-IP 默认设置、只针对局域网域名和少数特殊应用做过滤名单,是维护成本和体验之间更平衡的做法。

下载Clash