Fake-IP 模式原理详解:DNS 增强模式与 Redir-Host 怎么选

一、Fake-IP 改变的是 DNS 回答，不是节点出口

在 Clash 或 Clash Meta（现名 mihomo）的配置里，dns.enhanced-mode 决定内置 DNS 如何回答查询。常见取值是 fake-ip 与 redir-host。它们不负责选择订阅、不改变节点协议，也不能代替规则模式或 TUN 模式。

Fake-IP 会给域名分配一个合成地址，并保存“域名 ↔ 合成地址”的映射。应用向这个地址建立连接时，核心先还原域名，再进行规则匹配与出站处理。这个地址不是网站服务器的真实地址，也不是代理节点的 IP。

为什么常见地址是 198.18 开头？

常见配置使用 198.18.0.1/16 作为 Fake-IP 地址池。它位于为网络设备基准测试保留的 198.18.0.0/15 地址空间内，不是公网网站应当直接访问的目标。配置写成 /16，表示地址池取其中一部分，并不表示整个保留范围只有这一段。

因此，DNS 查询出现 198.18.x.x 本身不代表解析被篡改。关键是后续连接能否回到持有映射的同一个核心。如果应用拿到合成地址，却绕过 TUN 和其他透明接管路径直接连接，访问通常就会失败。

二、从域名查询到连接建立：两种模式的差别

Fake-IP 的典型处理顺序

应用查询一个域名，例如 example.com，查询进入核心 DNS。
核心分配或复用一个合成 IPv4 地址，并向应用返回结果。
应用连接该地址，流量由 TUN 等接管方式送回核心。
核心根据映射找回域名，依次检查规则，选择直连或代理出口。
在需要真实 IP 时再进行解析；若代理协议与出站设置允许传递域名，也可由远端完成解析。

这个过程可以减少应用开始连接之前等待真实 DNS 结果的时间，也让核心更容易拿到原始域名。它并不意味着“整个连接永远不查 DNS”。直连、IP 类规则、部分出站协议或特定解析策略，仍可能触发真实解析。

Redir-Host 的典型处理顺序

Redir-Host 通常先向上游解析器查询真实地址，再把地址返回给应用。核心可结合 DNS 缓存中的关联信息，在连接进入时恢复域名。若 DNS 没经过核心、缓存已经丢失，或多个域名共享同一地址，域名恢复可能不完整；流量嗅探能在部分协议中补充信息，但不是对所有连接都有效。

对照项目	Fake-IP	Redir-Host
应用收到的 IPv4 结果	通常为地址池内的合成地址	通常为上游返回的真实地址
回答前是否等待真实解析	普通合成回答通常不需要等待	缓存未命中时通常需要等待
域名规则所需的信息	主要来自合成地址映射	依赖 DNS 关联、显式代理信息或嗅探等
常见兼容性关注点	地址校验、局域网发现、绕过接管的连接	真实解析延迟、解析结果与出口的匹配

对使用 HTTP CONNECT 或 SOCKS 域名请求的显式代理连接，核心本来就可能直接获得目标域名，不一定经历上面的系统 DNS 流程。因此，仅在浏览器中设置代理后访问网页，不能独立证明 Fake-IP 的 DNS 接管已经正常。

三、按场景选择，不把 Fake-IP 当成网速开关

TUN 接管日常应用：可以先测试 Fake-IP。前提是 DNS 与后续连接都进入核心，且地址池没有与现有网络冲突。
企业内网、校园网、NAS 与打印机：先确认内网 DNS 能被访问，再对相关域名做例外。只有少数域名不兼容时，无需立刻全局切换模式。
应用要求 DNS 返回真实地址：先加入精确的过滤条目；若此类应用很多，或排除范围难以维护，再对比 Redir-Host。
只使用浏览器系统代理：先确认浏览器实际使用的代理协议与 DNS 路径。没有必要仅因看到一个模式名称就开启 TUN 或改写整份 DNS 配置。

Fake-IP 可能改善首次连接的解析等待，但不会提高订阅带宽、降低节点倍率，也不会修复拥塞线路。下载速度低时，应分别观察 DNS 耗时、连接建立时间与持续传输速度，避免把三类问题混在一起。

四、fake-ip-filter：只让必要域名返回真实地址

fake-ip-filter 在默认黑名单语义下表示：这些域名不使用合成地址，而是走正常解析。它不是代理绕过列表。域名进入过滤列表后，连接仍会继续匹配 rules；需要直连的业务，还要检查对应规则是否指向 DIRECT。

下面是面向 mihomo 的局部示例。127.0.0.1:1053 是便于手动验证的本机监听地址，并不自动成为系统 DNS。合并到现有配置时，只保留一个顶层 dns:，同时保留原配置需要的解析分流、上游地址与其他字段。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - localhost
    - "+.lan"
    - "+.home.arpa"
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

这里的上游地址仅用于展示结构，实际应选择当前网络可达、符合内网需求的解析器。+.home.arpa 在 mihomo 的域名匹配语法中可覆盖该域名本身及其子域。若使用旧版 Clash 核心，需要先检查其支持的字段与匹配语法；不能假定旧核心支持 fake-ip-filter-mode。

适合逐项验证的排除对象

自建局域网域名：例如 nas.home.arpa。如果它只在路由器 DNS 上存在，还需要让该域名使用内网解析器。
需要真实地址校验的应用域名：应用可能比较 DNS 结果与服务端返回的地址。先从日志中确认实际查询域名，再添加精确条目。
特定游戏或设备发现服务：仅在观察到 DNS 合成地址导致异常后排除。游戏连接还可能涉及 UDP、NAT 与中继服务，过滤域名不能修复这些独立问题。

.local 通常涉及 mDNS，与普通单播 DNS 不同。即使把相关名称写入过滤列表，也不等于 TUN 会自动转发组播发现数据。投屏或打印机找不到时，要同时检查局域网访问权限、组播路径和防火墙。

五、内网解析与规则分流需要分别配置

“返回真实地址”“向哪台 DNS 查询”“连接走哪个出口”是三个独立问题。例如 NAS 使用 nas.home.arpa，路由器地址为 192.168.1.1，可以在上面的示例中增加解析策略，并把直连规则放在可能抢先命中的宽泛规则之前。

# 以下字段合并进已有 dns，不要再创建第二个 dns。
dns:
  nameserver-policy:
    "+.home.arpa": "192.168.1.1"

# 以下条目加入已有 rules，并注意匹配顺序。
rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT

这是合并位置示意，不是一份可直接替换订阅的完整配置。示例中的 192.168.1.1 必须换成实际内网 DNS；若当前网络不能访问它，过滤列表再正确也无法得到有效回答。

订阅更新可能覆盖手动改动。使用客户端提供的覆写、扩展配置或合并功能时，应先确认最终生成的运行配置：过滤条目是否保留、解析策略是否合并、直连规则是否位于兜底规则之前。界面显示“保存成功”不等于核心已加载新字段。

六、用 DNS 查询和连接记录验证配置

第一步：确认正在运行的核心配置

记录客户端显示的核心名称与版本，检查运行配置里的 enhanced-mode、listen、过滤列表及 TUN DNS 劫持设置。客户端界面可能对字段做二次生成，应该以加载后的配置与日志为准。若核心报未知字段，先修正兼容性，不要带着错误继续测试。

第二步：直接查询本机 DNS 监听端口

若实际监听与前面的示例一致，在安装了 dig 的系统上执行：

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 nas.home.arpa A

Windows 可用 nslookup 的交互方式指定端口：

nslookup
> server 127.0.0.1
> set port=1053
> set type=A
> example.com
> nas.home.arpa
> exit

第一项若没有被过滤，通常应返回地址池内的 IPv4 地址；第二项只有在内网 DNS 确实配置了该记录时，才应返回对应内网地址。不要照抄某个固定的 198.18.x.x 作为正确答案，地址分配会随映射状态变化。

第三步：检查系统实际使用的 DNS 与连接路径

关闭应用已有连接，重新发起访问，查看客户端“连接”页中是否出现目标域名、命中规则和出站策略。
如果手动 DNS 查询正常、应用访问失败，检查系统 DNS 是否进入核心，以及 TUN 是否接管了合成地址连接。
如果应用使用自己的加密 DNS，先记录设置，再临时关闭该功能做对照。应用内 DoH 查询不一定经过核心的普通 DNS 监听。
如果只有 IPv6 路径异常，单独检查 AAAA 查询、IPv6 路由与接管设置。一次 A 记录测试不能代表 IPv6 也正常。

切换模式后可以在 Windows 执行 ipconfig /flushdns 清理系统解析缓存，再重启测试应用。浏览器、应用和核心还可能各自保留缓存或长连接，因此仅刷新网页不一定触发全新的 DNS 查询。

七、常见故障：先确定失效的是哪一段

关闭客户端后，网站仍尝试连接 198.18 地址

这通常需要检查残留 DNS 缓存、旧连接以及未恢复的系统网络设置。恢复正常 DNS 与代理设置，清理系统缓存，并关闭后重新打开应用。不要尝试给合成地址添加公网网关；缺少映射与接管时，它不是可直连的网站地址。

添加过滤后，内网站点还是打不开

先查询过滤后的真实 DNS 回答。若返回不存在或超时，问题在解析路径；若已返回正确内网 IP，再看连接规则、路由与防火墙。过滤列表只解决“不再返回合成地址”，不会自动发现内网 DNS，也不会自动放行局域网。

网页正常，但 ping 合成地址失败

ping 使用 ICMP，不等同于网页的 TCP 或 QUIC 请求。不同核心与接管方式对 ICMP 的处理不同，合成地址的 ping 结果也不是节点延迟。应以实际应用访问、连接记录和针对目标服务的测试为主。

改成 Redir-Host 后恢复，是否就该长期使用？

可以先保留能正常工作的配置，再定位差异。如果只有一个业务受影响，优先尝试精确过滤与正确的内网解析；如果大量应用都依赖真实 DNS 地址，Redir-Host 也可以作为长期方案。判断标准是连接可复现、规则命中符合预期、维护成本可控，而不是哪种模式名称更先进。