Clash Fake-IP 模式原理：虚拟地址池如何缩短解析等待及其适用场景

Fake-IP 的作用：先返回映射地址，再处理连接

开启 Clash 的 Fake-IP 模式后，DNS 查询可能得到 198.18.0.2 一类地址。它不是目标网站的公网地址，也不是代理节点地址，而是内核为域名分配的临时映射。应用随后访问这个地址，流量被同一内核接管，内核再根据映射找回域名，执行规则匹配和出站连接。

这套机制把“给应用一个可连接的地址”和“确定真实服务器地址”分开。对于能够把域名交给远端解析的代理出站，客户端不必先在本地完成目标域名的真实解析，应用就能进入连接阶段。它主要减少的是连接前置的解析等待，不会直接提高线路带宽，也不能保证所有网页都更快。

198.18.0.0/16 为什么不像公网地址

198.18.0.0/15 是为网络设备基准测试保留的 IPv4 地址段，并非普通公网服务地址。Clash 配置常从其中取用 198.18.0.0/16，常见写法为 fake-ip-range: 198.18.0.1/16。该前缀覆盖 65,536 个 IPv4 地址，但不能将这个数字直接理解为内核保证支持的同时映射数量。

地址池由内核分配、记录和回收。某个域名今天对应 198.18.0.2，下次重启或映射变化后未必仍然相同，因此不应将虚拟地址写入长期静态路由、服务器允许列表或应用固定配置。如果企业网络、实验环境或其他 VPN 已使用这个网段，应先检查路由冲突，再决定是否调整地址池。

Fake-IP 与 redir-host：DNS 等待发生在哪里

两种模式的主要区别是“返回给应用什么地址”，不是“是否使用代理”。规则模式、全局模式决定连接如何选择出站；enhanced-mode 决定 DNS 增强处理方式，两者属于不同层级。

一次代理访问的流程对比

1. redir-host：应用查询域名，Clash 向上游请求真实地址，收到结果后回复应用；应用再连接该地址，连接由规则选择出站。
2. Fake-IP：应用查询域名，Clash 保存“域名—虚拟地址”映射并回复；连接进入内核后还原域名，再按规则选择出站。
3. 代理支持域名目标时：真实解析可以在远端进行；若最终选择直连，或者规则需要判断目标 IP，则仍可能触发本地真实解析。

例如，假设某次未缓存的上游 DNS 查询耗时 120 毫秒，Fake-IP 有机会让应用不必在发起连接前等待这段查询。这里的 120 毫秒只是流程示意，不是实测加速承诺。最终耗时还受规则、节点握手、远端解析和服务器响应影响，不能直接断言整页加载缩短相同时间。

同样，Fake-IP 不等于“完全不用 DNS”。节点服务器本身可能需要解析，直连域名需要真实地址，某些 IP 规则也需要解析结果。若应用已经通过 HTTP 或 SOCKS 代理直接提交域名，它的访问路径也未必经过上述虚拟地址分配过程。

最小配置：启用映射并保留局域网解析

以下示例用于说明 Clash Meta（现称 mihomo）常见的字段关系，并非可直接替换订阅的完整配置。操作前备份当前配置，保留原有节点、策略组与规则，再将 DNS 字段合并到客户端支持的覆写配置中。不要在同一 YAML 文件里重复创建两个顶层 dns 键。

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

• enable：启用内核 DNS；仅修改模式而未启用 DNS，无法形成预期查询链路。
• listen：示例监听本机 UDP/TCP 1053 端口，便于独立测试；系统默认 DNS 使用 53 端口，不会自动改为访问 1053。
• enhanced-mode：选择 fake-ip；对照测试时可改为 redir-host，其余条件保持一致。
• nameserver：提供需要真实解析时使用的上游。示例为普通 DNS，未提供传输加密；应结合网络可达性与隐私需求选择。
• fake-ip-filter：按通常的排除模式，让匹配域名返回真实解析结果，而不是从地址池分配地址。

mihomo 的部分版本提供 fake-ip-filter-mode，允许改变过滤名单语义。本文按排除模式说明；如果现有配置显式使用了 whitelist 模式，就不能再把列表理解为“这些域名不使用 Fake-IP”。不同客户端附带的内核版本和默认过滤项也可能不同，应以实际生效配置为准。

fake-ip-filter 白名单：按故障域名添加例外

日常所说的“Fake-IP 白名单”，通常指“不分配虚拟地址的例外列表”。加入列表并不代表自动直连，也不代表自动使用路由器 DNS。域名是否直连由规则决定，向谁查询真实地址由 DNS 策略决定，三个设置需要分别核对。

局域网设备和私有域名

打印机、NAS、路由器管理页以及企业内部服务，经常依赖局域网 DNS。对于 home.arpa 或组织内部域名，可以添加精准后缀例外，并将该域名的解析交给正确的本地 DNS。公共 DNS 通常不知道内部主机地址，仅加过滤项仍可能得到不存在的域名响应。

.local 常由 mDNS 解析，而 mDNS 使用的发现机制不等同于普通单播 DNS。将它放入过滤列表只解决不分配 Fake-IP 的问题；如果设备发现仍失败，应继续检查局域网访问权限、多播和 TUN 路由，而不是不断增加公共上游。

校验解析地址或跨设备传递地址的应用

部分游戏、语音、时间同步、设备发现程序，会检查解析结果，或把解析出的 IP 交给另一台设备使用。另一台设备没有本机内核的映射，就无法凭这个虚拟地址连接目标。此时应从连接日志找出具体域名，先添加单个例外，再复测完整功能。

• 优先精确匹配：仅一个服务异常时，先加入其实际查询域名，不要直接排除整个大型域名后缀。
• 按症状验证：网页能打开不代表语音、联机或设备发现正常，测试应覆盖原先失败的操作。
• 不要按应用类别全部排除：游戏、NTP 或 STUN 并不天然与 Fake-IP 冲突，是否需要例外取决于实现与接管方式。

在 mihomo 常见域名匹配语法中，+.home.arpa 用于匹配该域及其子域。若使用较旧的 Clash 内核，应先核对对应语法支持情况。切换过滤项后，还要清理应用和系统缓存，否则应用可能继续使用修改前取得的虚拟地址。

TUN 与系统代理：确保虚拟地址能够回到内核

Fake-IP 是 DNS 行为，TUN 是流量接管机制，两者可以配合，但不是同一个开关。TUN 通常更适合接管不遵守系统代理的应用；系统代理主要影响主动采用系统 HTTP、HTTPS 或 SOCKS 设置的程序，不能保证接管任意应用访问虚拟地址的连接。

先测试 DNS，再测试连接路径

1. 确认配置已加载，且 DNS 监听端口确实为 127.0.0.1:1053。若提示端口占用，先排查其他 DNS 服务或重复运行的内核。
2. 直接查询该端口，确认一个不在过滤列表中的域名是否获得地址池内的 A 记录。
3. 检查系统或应用实际使用的 DNS。直接查询测试成功，不代表系统默认查询已经进入 Clash。
4. 访问目标并查看连接日志，确认能恢复目标域名，且命中的规则和出站符合预期。

# macOS / Linux：系统已提供或已安装 dig 时使用
dig @127.0.0.1 -p 1053 example.com A

# 对比默认解析链路
dig example.com A

第一条命令可能返回 198.18.0.2 等池内地址，具体分配值不固定。若第一条得到虚拟地址、第二条仍得到公网地址，应优先检查 DNS 入口，而不是认为 Fake-IP 配置没有加载。浏览器自行使用的加密 DNS、应用内置解析器及缓存，也可能让实际访问走另一条路径。

TUN 配置中的 dns-hijack 可用于接管匹配的 DNS 流量，常见目标写法包括 any:53，但具体支持和覆盖范围取决于内核、平台与协议。它不是任意 DNS 的总开关：通过 HTTPS 443 端口发送的 DoH，并不会因为接管了传统 DNS 53 端口就自动进入内核 DNS。

常见故障：地址池、缓存与规则逐项定位

拿到 198.18 地址后网页打不开

先检查该连接是否出现在内核日志。如果完全看不到，通常需要排查应用绕过代理、TUN 路由未生效或其他 VPN 抢占路由。如果能看到域名和策略，再检查节点可用性、直连 DNS 与规则，而不是立即切换整个 DNS 模式。

重启内核后，少数应用暂时失效

应用可能缓存了旧虚拟地址，而内核已重新建立映射。先退出并重新打开故障应用，再按系统要求清理 DNS 缓存。Windows 可在终端执行 ipconfig /flushdns；采用 systemd-resolved 的 Linux 可用 resolvectl flush-caches。这些命令不保证清除浏览器或应用自身的缓存。

部分内核提供 profile.store-fake-ip 保存映射，用于减轻重启前后不一致的问题，但它不能修复 DNS 被绕过、多个内核分别维护地址池或路由冲突。不要在没有确认支持情况时，直接将该字段加入旧内核配置。

加入过滤列表后仍然打不开

先重新查询，确认结果已经从虚拟地址变为真实地址。如果仍是池内地址，检查过滤语法、模式及缓存；如果已是真实地址，则继续检查该内部域名是否由正确的 DNS 解析，以及连接是否走了正确出站。过滤项只改变地址生成方式，不替代分流规则。

什么时候保留 Fake-IP，什么时候比较 redir-host

• 优先保留 Fake-IP：DNS 与连接均由同一内核处理，主要按域名分流，希望减少代理访问前的本地解析等待。
• 先添加精准例外：只有少数内部服务、设备发现或特定应用异常，其他访问正常。
• 对照测试 redir-host：大量程序依赖真实 IP，或当前环境无法稳定接管虚拟地址连接时，比较两种模式的实际兼容性。

每次只改一个变量，并记录域名、DNS 返回值、命中规则和错误信息。先证明查询进入了正确的 DNS，再证明连接回到正确的内核，最后判断上游解析与出站质量。这比同时修改地址池、节点和全部规则更容易找出原因，也能保留可以回退的配置。