Fake-IP 模式原理详解:DNS 假地址映射与局域网设备兼容问题

1. Fake-IP 的作用：以映射地址保留目标域名

Fake-IP 是 Clash 系列内核的一种 DNS 工作模式。应用查询域名的 IPv4 地址时，内核可以先从指定地址池分配一个地址，再记录“域名与假地址”的对应关系。这个地址用于本机或受管网络内的连接接管，不是网站服务器的公网地址。

常见配置使用 198.18.0.1/16 作为地址池配置值，落在 198.18.0.0/15 基准测试保留地址空间内。它不同于 192.168.0.0/16 等私有局域网网段，也不应直接发往公网。看到此类 DNS 响应，本身不能说明解析异常。

一次连接的处理顺序

应用查询 example.com，查询进入内核的 DNS 服务。
内核分配地址池中的一个地址，并建立映射。例如，某次分配结果可能为 198.18.0.2；具体地址不固定。
应用向这个假地址发起连接，TUN 或其他透明接管路径把连接送回同一内核。
内核从映射表恢复目标域名，按规则选择直连或代理出口。
直连通常仍需解析真实地址；代理出口能否把域名交给远端处理，取决于出站协议与配置。

关键条件是查询和后续连接形成闭环。仅让设备从 Clash 获得假地址，却没有让发往该地址的流量回到对应内核，会出现“DNS 有响应，网页打不开”。单独打开 DNS 监听端口不等于建立了这个闭环。

速度收益的边界

Fake-IP 可以缩短应用等待真实 DNS 结果的阶段，也让内核更容易按原始域名匹配规则。它不会降低网络链路的物理时延，不能保证所有网站都更快。直连解析、代理握手、TLS 建连和服务器响应仍可能成为主要耗时，因此不能把假地址分配速度等同于网页加载速度。

2. Fake-IP 与 redir-host：返回内容与接管条件

比较项	Fake-IP	redir-host
DNS 响应	对符合条件的查询返回地址池中的映射地址	返回上游解析得到的真实地址
域名关联	通过假地址映射恢复域名	通过 DNS 记录关联等机制识别域名，存在共享 IP 等限制
连接前的等待	可先分配假地址，不必先取得目标真实地址	通常需要先完成真实地址解析
网络要求	发往假地址的流量必须回到对应内核	真实地址可正常路由，但分流仍依赖接管与规则
兼容性关注点	地址检查、跨设备连接、旧映射缓存	上游解析结果、域名关联与 DNS 路径

选择模式应依据实际接管方式。桌面设备启用 TUN、且 DNS 查询由同一内核处理时，Fake-IP 的路径比较清晰。打印机、电视和游戏主机的网络行为较复杂，如果只调整了 DNS 而未设置透明代理路由，不能直接套用桌面配置。

系统代理又是另一条路径。HTTP 代理请求可能直接携带域名，不一定使用本地 DNS 查询结果。浏览器能访问网站，并不能证明系统 DNS 和 TUN 都已正常工作；同样，某个诊断命令不通，也不能代表 HTTP 代理失效。

3. 最小 DNS 配置与 fake-ip-filter 写法

下面是 DNS 配置片段，不是包含节点、代理组与规则的完整配置。示例使用本机 1053 端口，避免直接占用系统常用的 53 端口。TUN 的 DNS 劫持或系统 DNS 转发仍需另行配置；操作系统的普通 DNS 地址输入框通常不能填写自定义端口。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '+.lan'
    - '+.local'
    - '+.home.arpa'
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

字段含义与适用范围

enable：启用内核 DNS 服务。客户端界面可能还存在独立的 DNS 覆盖开关，应以最终生效配置为准。
listen：这里只接受本机查询，不向局域网开放 DNS 服务。
ipv6: false：控制该 DNS 模块对 AAAA 查询的处理，不代表关闭操作系统 IPv6，也不保证其他解析器不返回 IPv6 地址。
enhanced-mode：指定 DNS 增强模式。示例选择 fake-ip。
fake-ip-filter：在常见的默认黑名单语义下，匹配域名不分配假地址，转为获取真实解析结果。
nameserver：示例列出两个上游地址。列表顺序不是“国内优先、国外备用”的分流策略，实际使用还受内核实现和其他 DNS 字段影响。

+.home.arpa 用于匹配该域及其子域。home.arpa 是家庭网络域名空间；.local 常与 mDNS 关联，部分请求通过 UDP 5353 多播发送，并不经过这里的普通 DNS 监听器。加入过滤列表不能替代 mDNS 转发或设备发现机制。

mihomo 提供了更细的过滤模式选项，例如 fake-ip-filter-mode。复制配置前先核对内核支持情况：白名单模式会改变过滤列表的含义，不能继续把每个列表项都解释为“排除”。原版 Clash、不同分支和不同发行版本的字段支持并不完全一致。

4. 局域网设备兼容：先区分解析、路由和发现

NAS 域名返回假地址

例如 NAS 的真实地址是 192.168.1.20，家庭域名为 nas.home.arpa。若查询返回 198.18 开头的地址，先检查该域名是否命中过滤，再检查它是否由家庭 DNS 解析。只有把两步都处理好，才能稳定获得私有地址。

在 mihomo 中，可以使用 nameserver-policy 为家庭域名指定解析器。下面片段假定路由器 DNS 为 192.168.1.1，且运行内核的设备能访问它。应合并到同一个 dns 对象中，不要重复创建第二个顶层 dns 键。

dns:
  nameserver-policy:
    '+.home.arpa': '192.168.1.1'

这个片段不包含前文的过滤列表，合并时需要保留 fake-ip-filter。还要检查路由器有没有把同一查询再次转回 Clash，否则可能形成 DNS 转发循环。

打印机、电视与投屏设备发现失败

设备发现可能使用 mDNS、SSDP 或广播，不只是普通 DNS。mDNS 常用 224.0.0.251:5353，SSDP 常用 239.255.255.250:1900。客户端处在访客 Wi-Fi、不同 VLAN 或启用无线客户端隔离时，即使域名解析正常，也可能无法发现设备。

先用设备的实际私有 IP 访问其管理页，确认基础连通性。
再查询设备域名，确认是否获得预期私有地址。
只有自动发现失败时，检查组播、广播与网段隔离，不要反复扩大 DNS 过滤列表。

手机获取假地址，连接却进入另一台网关

假地址映射属于具体内核实例。手机向网关 A 查询 DNS，却通过网关 B 发送连接时，B 通常没有 A 的映射。重启 A 后，手机继续使用旧缓存也可能出现类似问题。家庭网络应统一 DNS 与透明代理路径，不能把某台电脑的 Fake-IP DNS 当作独立公共 DNS 分发给所有设备。

5. 排查步骤：从 DNS 应答定位到实际出口

第一步：直接查询内核 DNS

Linux 或 macOS 已安装 dig 时，可直接访问示例中的本机端口。以下命令是检查方法，不预设固定输出：

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

前一条在正常的 Fake-IP 分配路径下应返回地址池内的地址。后一条在过滤与家庭 DNS 策略正确时，应返回实际家庭记录。超时优先检查 DNS 监听和进程状态；返回 NXDOMAIN 则检查记录是否存在、是否选错解析器。

第二步：检查系统实际使用的解析器

Windows 可用 ipconfig /all 查看网络适配器的 DNS 地址，用 nslookup example.com 检查默认查询路径。浏览器的安全 DNS、应用内置 DoH、VPN 和其他虚拟网卡都可能改变路径。命令行与浏览器使用不同解析器时，结果不同并不罕见。

ipconfig /all
nslookup example.com
ipconfig /flushdns

ipconfig /flushdns 只清理 Windows DNS 客户端缓存，不会同时清除浏览器、应用和内核映射缓存。修改模式或重启内核后，应重启仍持有旧连接的应用，再进行相同查询。不要只刷新页面便断言配置没有生效。

第三步：核对规则命中与私有网段

在客户端连接列表或日志中检查目标域名、目标地址、命中规则和出口。为家庭网络安排直连时，可以参考下列规则片段，并放在宽泛代理规则和最终 MATCH 之前：

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve

这不是完整规则集，应合并到现有 rules 列表。no-resolve 表示不为了匹配该 IP 规则而额外触发域名解析；已有目标 IP 时仍可参与匹配。内核已经恢复出域名的连接，可先由前面的域名规则命中，不必依赖 IP 规则兜底。

不要将整个 Fake-IP 地址池加入直连规则，试图让操作系统直接访问这些地址。假地址需要先交给维护映射的内核处理，不能当作真实网站地址路由出去。

6. 常见问题与模式切换条件

ping 到 198.18 开头的地址，是否代表网站故障？

不是。它可能只是当前域名的假地址。ICMP 的处理路径与 TCP、UDP 代理不同，不能单凭 ping 结果判断网页访问。应结合 DNS 应答、连接日志和实际应用请求检查。

fake-ip-filter 能否解决所有游戏和智能设备报错？

不能。它只调整匹配域名的地址分配行为。UDP 转发、NAT 类型、应用硬编码 IP、证书错误和组播隔离需要分别排查。只有确认应用依赖真实 DNS 地址，才优先对具体域名添加过滤。

开启 Fake-IP 后是否必须开启 TUN？

不绝对。TUN 是常见的连接接管方式，路由器透明代理也可能完成同一任务。必要条件是发往假地址的相关流量由维护该映射的内核处理，而不是界面上某个开关必须处于开启状态。

什么时候考虑切换到 redir-host？

当特定设备持续校验 DNS 地址、需要把解析结果交给不经过该内核的其他设备，或暂时无法统一 DNS 与连接路径时，可以测试 redir-host。切换后清理相关缓存并重新建立连接，同时复查域名规则和真实 DNS 解析路径。

稳定配置的判断依据是三项一致：域名由预期解析器处理，连接进入正确内核，出口符合规则。先对一个应用、一个域名完成验证，再扩大过滤或调整模式，通常比同时改动 DNS、TUN 和整套订阅更容易定位问题。基础字段可参照协议参考，网络术语可查阅概念速查。