Fake-IP 模式工作原理详解:DNS 映射池、劫持流程与适用场景

DNS 解析在代理链路里的位置

任何一次网络访问都从域名解析开始:应用先向系统或客户端内置的 DNS 模块询问某个域名对应哪个 IP,拿到答案后再发起 TCP 或 UDP 连接。在没有代理软件介入的情况下,这个 IP 是真实的、可以直接用来路由和分流的信息。但对 Clash / mihomo 这类基于规则做流量分发的工具来说,单纯依赖 IP 会带来一个麻烦:很多域名背后是 CDN,同一个网站在不同时间、不同地区解析出的 IP 完全不同,基于 IP 段写死的规则很快就会失效。于是规则引擎更希望拿到的是域名本身,而不是一个漂移不定的 IP。这就是 DNS 模式设计要解决的核心问题——如何让"域名信息"能够传递到连接建立和规则匹配的每一个环节。

Clash 的 DNS 模块提供了几种工作模式,其中最常被讨论、也最容易被误解的就是 Fake-IP。理解它,需要先放下"DNS 解析出的 IP 就是要连接的真实地址"这个默认假设。

Fake-IP 的映射池机制

Fake-IP 模式的思路是:客户端接管本机的 DNS 请求,当应用查询某个域名时,不去真正联系上游 DNS 服务器要一个真实 IP,而是从一个预留的私有网段(默认是 198.18.0.0/16)里,按顺序或按缓存策略分配一个从未使用过的 IP,直接返回给应用。这个 IP 本身不指向任何真实服务器,它只是一个"占位符",客户端会在内部维护一张映射表,记录"这个虚构 IP 对应哪个域名"。

整个流程可以拆成三步:

1. 应用发起 DNS 查询,查询请求被 TUN 或系统 DNS 劫持到 Clash 内部的 DNS 服务器组件。
2. Clash 检查映射池,若该域名此前没有分配过 Fake-IP,就取一个尚未占用的地址,建立"域名 ↔ 虚构 IP"的双向记录并写入内存表。
3. Clash 把这个虚构 IP 作为 DNS 应答返回给应用,应用拿着这个 IP 去建立连接。

关键点在于第三步之后:应用用虚构 IP 发起连接时,这个连接会经过 TUN 网卡或系统代理进入 Clash 的转发引擎。此时 Clash 并不会真的向 198.18.x.x 这个地址发包,而是先查一遍映射表,把虚构 IP 反查回域名,拿到真实域名后,再按代理规则决定走哪个代理组,并对真实域名重新做一次实际的 DNS 解析(或者直接把域名交给支持 SNI/HTTP Host 的下游代理去处理)。这一步叫作"连接阶段还原",是 Fake-IP 能正常工作的核心——域名信息全程被保留,虚构 IP 只是一个临时载体,不会真正参与到底层网络传输里。

为什么规则匹配更准了

因为 Fake-IP 让"域名"能一路传递到连接建立环节,规则引擎在做 DOMAIN-SUFFIX、DOMAIN-KEYWORD、RULE-SET 这类基于域名的匹配时,拿到的始终是可靠的原始域名,而不是随时可能变化的 CDN 出口 IP。这对于 CDN 密集的场景尤其重要——同一个域名可能今天解析到 A 记录,明天解析到另一批 IP,如果规则写的是 IP 段,很容易出现"昨天能匹配、今天匹配不上"的情况。域名相对稳定得多,基于域名的规则集也是当前 mihomo 生态里规则更新最频繁、覆盖最广的形式。

另外,Fake-IP 模式下客户端不需要在系统层面每次都发起真实的 DNS 查询才能判断走不走代理——虚构 IP 分配和规则匹配可以在本地内存里完成,减少了一轮网络往返,这也是很多用户反馈开启 Fake-IP 后网页打开速度略有提升的原因之一。

Fake-IP 与 Redir-Host 的差异

在 Fake-IP 出现之前,另一种常见方案是 Redir-Host:客户端劫持 DNS 请求后,不返回虚构地址,而是直接向真实上游 DNS 服务器查询,拿到真实 IP 并原样返回给应用。规则匹配这一步则依赖客户端在 DNS 查询阶段就记下"域名对应哪些 IP",随后靠这份记录在连接阶段反查回域名。表面上两者都实现了"域名参与规则匹配",但工作细节和适用边界并不相同。

简单说,Fake-IP 在速度和规则准确性上更有优势,是当前 TUN 模式下的默认选择;Redir-Host 因为应用拿到的始终是真实 IP,在一些直接依赖 IP 通信、不经过域名解析习惯的场景里兼容性更稳妥,但整体已经逐渐被 Fake-IP 加白名单排除的组合方案取代。

哪些场景必须用 fake-ip-filter 排除

虚构 IP 只是一个"给 Clash 内部用的占位符",一旦某个应用不经过 Clash 的连接劫持逻辑,直接把这个 IP 当作真实地址使用,就会出问题。常见的几类场景需要显式配置 fake-ip-filter,把对应域名排除在 Fake-IP 分配范围之外,让它们走真实 DNS 解析:

• 局域网内部服务与路由器管理页面——像 *.lan、router.asus.com 这类指向本地网络设备的域名,如果被分配了虚构 IP,浏览器会尝试连接一个根本不存在的地址,导致管理页面打不开。
• 需要精确获取真实 IP 的应用——部分网盘客户端、直播推流工具、P2P 类应用会在应用层直接读取 DNS 返回的 IP 用于展示或建立点对点连接,虚构 IP 对它们没有意义。
• 企业内网与 VPN 场景中的私有域名——公司内部系统域名往往解析到私有网段,这类域名同样应加入排除列表,避免与代理逻辑产生冲突。
• 已知与 Fake-IP 存在兼容问题的客户端组件——例如某些系统自带的网络检测、连通性探测服务,建议按官方文档或社区维护的规则集统一排除,而不是逐条手动添加。

实践中不需要从零手写这份排除列表:主流规则集仓库通常已经维护了一份较完整的 fake-ip-filter 建议清单,客户端在生成默认配置或使用规则订阅时也会带上一份基础版本,遇到具体应用打不开的情况再按需追加即可。

什么时候该开、什么时候该关

Fake-IP 模式的默认使用建议如下:

• TUN 模式下建议保持开启。TUN 模式接管全局网络栈,需要一套高效、准确的域名还原机制来配合规则引擎,Fake-IP 正是为这种场景设计的,也是大多数客户端在 TUN 模式下的默认 DNS 类型。
• 纯系统代理模式(HTTP/SOCKS)下可以按需选择。如果只是让浏览器等支持系统代理设置的应用走 Clash,Redir-Host 或直连上游 DNS 都是可行的替代方案,差异主要体现在规则匹配的精细度上。
• 遇到局域网设备、内网系统访问异常时,先检查 fake-ip-filter,而不是直接关闭整个 Fake-IP。大部分"开了代理内网设备连不上"的问题,根源是排除列表没覆盖到对应域名,针对性追加规则比放弃整套机制更划算。
• 对精确 IP 有强依赖的少数应用,单独走直连或排除域名。没必要因为个别应用的特殊需求关闭全局 Fake-IP,规则分流本身就支持按域名或按进程做例外处理。

总体上,Fake-IP 不是一个"要不要开"的二选一开关,而是需要配合排除列表一起维护的动态机制。规则集社区在持续更新已知需要排除的域名,客户端也在不断优化虚构 IP 池的分配与回收策略,理解其工作原理之后,遇到具体问题就能快速判断该往哪个方向排查,而不是把整套 DNS 模式当作一个不可拆解的黑盒。