Fake-IP 模式原理详解:DNS 解析怎么被接管,哪些场景该开哪些该关
从 DNS 查询流程讲起,解释 Fake-IP 如何用保留网段假地址加速规则匹配、减少 DNS 泄漏,对比 Redir-Host 的差异,并列出局域网服务、游戏联机等需要关闭或加例外的典型场景。
普通 DNS 解析流程,以及代理场景下它带来的问题
访问一个域名之前,系统要先把域名翻译成 IP 地址,这一步叫 DNS 解析。默认情况下,操作系统把查询发给运营商或系统配置的 DNS 服务器,拿到真实 IP 后再建立连接。这个流程在没有代理的环境下没什么问题,但套上代理软件之后,至少会暴露两个麻烦。
第一个麻烦是泄漏。如果代理软件只接管了 TCP/UDP 流量,却没管住 DNS 查询,那么域名解析请求会绕过代理直接走本地网络出去,运营商或本地网络的监听方能看到用户在查询哪些域名,这就是常说的 DNS 泄漏——流量走了代理,查询记录却没走。
第二个麻烦是匹配时机。Clash 的分流规则里有大量基于域名的规则(DOMAIN-SUFFIX、DOMAIN-KEYWORD 等),这些规则天然更适合拿着域名字符串去匹配。但传统流程是先解析出 IP,应用层拿到的是一串数字,如果这时才做规则匹配,域名信息已经丢了,只能退化成基于 IP 段的匹配,规则库的维护成本和覆盖率都会打折扣。
Fake-IP 是什么:用保留网段的假地址顶替真实解析
Fake-IP 是 Clash / Clash Meta(mihomo)内核提供的一种 DNS 处理模式。核心思路很简单:客户端内置一个 DNS 服务器,拦截系统发出的所有域名查询,不去问真实 DNS,而是从一个预留的私有网段(常见默认是 198.18.0.0/16)里,给每个域名分配一个从未被公网使用的假 IP,并在内核里维护一张"域名 ↔ 假 IP"的映射表。
应用程序拿到这个假 IP 之后,会照常发起连接,连接请求进入 Clash 的流量接管层(TUN 模式或系统代理)。这时内核先查一下映射表,发现目标地址是个假 IP,立刻反查回对应的域名,规则匹配环节因此重新拿到了域名字符串,而不是一个失去上下文的 IP 数字。真正的域名解析动作,被推迟到规则判断"这条流量要走哪个代理节点"之后才执行,而且解析请求本身也是经代理节点转发出去的,不会在本地网络裸奔。
这样一来,前面提到的两个麻烦同时被解决:DNS 查询全程在代理链路内完成,不再裸露给本地网络;规则匹配拿到的始终是域名而不是提前固化的 IP,匹配准确率和响应速度都更有保障。
关键点:假 IP 只在本机内核里"临时存在",不会真正发到公网,也不会被其他设备识别,它的唯一作用是充当域名到规则引擎之间的一个中间令牌。
Fake-IP 与 Redir-Host:两种域名保留方式的差异
Clash 的 DNS 增强模式里,除了 Fake-IP,还有一种更早期的方案叫 Redir-Host。两者目标一致——把域名信息带到规则匹配环节——但实现路径不同,行为差异也直接影响到底该选哪一种。
| 对比项 | Fake-IP | Redir-Host |
|---|---|---|
| DNS 查询处理 | 拦截查询,返回本地生成的假 IP | 正常放行查询,拿到真实 IP |
| 规则匹配依据 | 反查映射表得到域名 | 依赖 SNI/Host 头等应用层字段还原域名 |
| 兼容性风险 | 非 HTTP/TLS 协议可能拿不到域名字段而误判 | 依赖真实 IP 的场景(如证书校验 IP)更少出问题 |
| 对无域名协议支持 | 部分协议缺 Host 信息时会分流不准 | 基本不受影响,因为用的是真实 IP |
| 当前主流建议 | mihomo 默认推荐,性能与准确率更平衡 | 逐步边缘化,多用于排查兼容性问题时对照 |
简单说,Fake-IP 是"先假装解析,靠内核映射表还原域名",覆盖面广、速度快,是目前 mihomo 内核的默认推荐;Redir-Host 是"老老实实拿到真 IP,再从协议头里抠域名字段",胜在稳,遇到某些不走标准 TLS/HTTP 的私有协议时更少翻车,但整体已经不是主流选择。日常使用直接用 Fake-IP 即可,遇到某个应用连不上再针对性排查,不需要一上来就整体切换回 Redir-Host。
哪些场景需要关闭 Fake-IP 或加例外
Fake-IP 不是万能开关,它假设"所有域名查询都可以先给假地址",但有些场景恰恰依赖"拿到的必须是真实 IP",这时就得关闭 Fake-IP 或者把对应域名加入例外名单(通常配置项是 fake-ip-filter)。
- 局域网内部服务发现:NAS、打印机、智能家居设备、局域网共享盘等,域名往往解析到
192.168.x.x或*.local这类内网地址,如果这些域名被塞进假 IP 逻辑,连接会被错误地送进代理链路而失败,建议把*.local、内网设备的自定义域名都写进fake-ip-filter。 - 游戏联机与局域网发现协议:很多游戏的联机大厅、语音服务需要拿到真实公网 IP 用于建立直连或 P2P 通道,假 IP 会破坏这类需要"看到真实地址"的握手逻辑,常见做法是把游戏相关域名整体排除在 Fake-IP 之外,或者干脆把游戏进程加入直连规则。
- 某些客户端直接做 IP 白名单校验:少数企业内网工具、部分支付/金融类客户端会在应用层校验请求方 IP 是否落在预期范围,假 IP 会导致校验失败,这类场景通常需要为对应域名单独设置直连或加入例外列表。
- 依赖 mDNS / 组播发现的设备:苹果生态的 AirPlay、AirDrop 等基于组播广播完成设备发现,与 DNS 解析路径不同,理论上不受 Fake-IP 影响,但如果发现异常,先排查 TUN 模式的路由劫持范围,而不是急着关掉 Fake-IP。
注意:开启 TUN 模式后,Fake-IP 的网段会被系统当作真实路由处理,如果这个网段与本地已有的内网地址段(比如公司 VPN 分配的私有网段)冲突,会出现莫名其妙连不上内网的问题。遇到这种情况,优先检查 fake-ip-range 是否与现有网络环境冲突,而不是直接归咎于代理软件故障。
配置与排查建议
动手调整 Fake-IP 相关配置前,先明确自己用的是哪个层面在起作用:DNS 层的映射表,还是 TUN 层的路由劫持,两者分开排查效率更高。
- 确认客户端 DNS 设置里
enhanced-mode是否为fake-ip,如果显示redir-host说明走的是另一套逻辑,前面章节的行为对照要反过来看。 - 检查
fake-ip-range使用的网段是否与本机现有网络(包括 VPN、虚拟机网卡)有重叠,重叠是导致内网访问异常的常见原因。 - 把明确需要真实 IP 的域名(内网服务、游戏大厅、组播设备)逐条加入
fake-ip-filter,不要图省事整体关闭 Fake-IP,那样会连带丢失前面提到的匹配加速与防泄漏效果。 - 怀疑某个连接异常与 Fake-IP 有关时,先打开客户端日志页观察该连接实际命中的规则与目标地址,确认是解析环节出的问题,还是规则本身写错了。
- 调整配置后重启一次代理内核而不只是重连节点,DNS 映射表和路由表通常是在内核启动阶段建立的,单纯切换节点不会重新生成。
总的来说,Fake-IP 是把域名解析这一步"往后挪"并"藏起来"的工程手段,目的是让规则匹配更准、DNS 查询更私密,绝大多数使用场景保持默认开启即可。真正需要关注的是那一小部分依赖真实 IP 语义的服务,针对它们加例外,而不是因为个别应用连不上就把整套机制关掉。