进阶配置 预计阅读 12 分钟

Clash Fake-IP 模式详解:DNS 映射原理与适用场景

解释 fake-ip 如何用保留地址段映射域名、与 redir-host 的差别,以及 fake-ip-filter 的设置要点和不适用的场景。

Fake-IP 原理：先返回映射地址，再按域名处理连接

开启 Fake-IP 后，查询网站域名时看到 198.18.x.x，通常是预期结果，而不是网站真的迁移到了这个地址。Clash 的 DNS 模块从指定地址池中分配一个合成 IPv4 地址，并在内部保存“域名与合成地址”的映射。应用拿着这个地址发起连接，内核接管连接后，再通过映射找回原始域名。

典型过程可以拆成四步。理解这条链路，比只记住 enhanced-mode: fake-ip 更有助于定位问题。

  1. 应用查询 www.example.com 的 A 记录，请求进入内核的 DNS 服务。
  2. DNS 模块分配地址池内的地址，例如 198.18.0.2，并记录它对应的域名。具体分配结果不固定。
  3. 应用向这个合成地址的 TCP 443 端口发起连接，流量通过 TUN 或其他透明接管机制进入内核。
  4. 内核还原域名，依据规则选择出站；直连或代理出站随后按自身需要完成真实地址解析与连接。

Fake-IP 可以让域名规则在建立连接时直接获得域名信息，减少部分场景对本地真实解析结果的依赖。但这不代表所有连接都完全不需要真实 DNS：直连目的地、需要 IP 信息的规则，以及代理节点本身的域名解析，仍可能触发查询。它也不是加密协议，不会自动把明文 DNS 变成加密 DNS。

Fake-IP 与 redir-host：差别在 DNS 回答和域名还原

redir-host 返回上游解析得到的真实地址；fake-ip 则在适用的查询中返回合成地址。两者都可以配合规则分流，但应用看到的地址不同，内核取得域名的方式也不同。

对比项fake-ipredir-host
应用收到的 A 记录通常为地址池内的合成 IPv4 地址上游返回的真实 IPv4 地址
域名关联方式通过合成地址映射找回域名依赖 DNS 缓存关联等信息，必要时可结合嗅探
本地真实解析依赖部分代理连接可推迟或交由远端解析回答应用查询前通常需要获得真实解析结果
常见兼容性边界程序校验地址、局域网发现、流量未被接管共享 IP 对应多个域名时，域名关联可能存在歧义
适合优先测试的情况TUN 接管稳定，主要运行浏览器与常规联网应用应用必须看到真实地址，或现有网络不便接管合成地址

不要把这两种模式理解成固定的速度排名。首次解析延迟、代理节点的 DNS 环境、规则是否触发 IP 查询，都会影响连接耗时。如果要比较，应在同一网络、同一节点、同一目标站点下重复测试，而不是用一次网页加载结果判断模式优劣。

mihomo DNS 配置：最小片段与生效条件

下面是适用于 mihomo 的 DNS 配置片段，不是包含节点与规则的完整配置。示例把 DNS 监听在本机 127.0.0.1:1053，便于独立验证；普通系统 DNS 设置通常只接受服务器地址、默认使用 53 端口，不能直接把这个 1053 端口当作系统 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:
    - "localhost"
    - "*.lan"
    - "*.local"
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  • enable 启用内置 DNS。仅设置模式而没有启用 DNS，不能得到预期的映射回答。
  • listen 控制监听地址与端口。回环地址只供本机访问，不会主动给整个局域网提供服务。
  • ipv6: false 用于简化这个示例的 AAAA 查询处理，不等于关闭操作系统的 IPv6 网卡或路由。
  • fake-ip-range 定义合成 IPv4 地址池。地址段要与现有 VPN、实验网络和路由规划核对，避免重叠。
  • nameserver 用于需要真实解析时的上游查询。示例中的 IP 写法是传统 DNS，上游必须从当前网络可达；加密 DNS 需要另行配置。

配置生效前先检查三件事

  1. 确认实际运行内核。 查看客户端的内核信息与启动日志。Clash、Clash Meta、mihomo 的字段支持范围不完全相同，不能把新内核的附加字段直接套到旧版本。
  2. 确认修改的是生效配置。 订阅文件可能在更新时被覆盖。优先使用客户端提供的覆写或合并功能，并在重新加载后检查最终配置。
  3. 确认 DNS 与连接都能进入内核。 测试查询发到 1053，只能证明 DNS 服务可用；应用发往合成地址的连接还需要 TUN 或其他透明转发机制接管。

fake-ip-filter：只排除需要真实地址的域名

在 mihomo 默认的黑名单过滤语义下，命中 fake-ip-filter 的域名不返回 Fake-IP，而走真实解析。它不是代理规则列表，不决定 DIRECT 或某个代理组；流量最后走哪里，仍由出站规则和其他路由配置决定。

前面的示例使用 *.lan 与 *.local 表达常见局域网命名后缀。域名匹配写法及特殊规则支持应以实际内核文档为准；如果配置另行设置了 fake-ip-filter-mode，务必先核对其语义，再解释过滤列表的效果。

按实际故障添加，不批量复制长列表

  • 企业内网域名： 例如某台内网服务需要返回 10.20.0.15，可以先排除它的完整域名。还要让查询进入企业 DNS，否则排除后仍可能得到不存在或错误的结果。
  • 校验目标地址的程序： 某些远程连接、设备发现或游戏组件会检查 DNS 答案。先针对确有问题的域名测试，再决定是否扩大匹配范围。
  • 局域网设备名称： 打印机、NAS 与投屏设备可能使用本地域名，但发现过程还可能涉及 mDNS 多播、广播或其他协议。过滤域名只能解决其中的 DNS 回答问题。

如果只有 nas.home.arpa 失败，先添加这个完整名称，比直接排除整个后缀更容易验证。排除范围越大，越多连接会回到真实地址解析路径，也越需要正确维护内网 DNS 与分流策略。NTP 同样不是必须一概排除的协议：只有设备或应用出现可复现的兼容性问题时，再针对其实际查询的时间服务器域名处理。

验证方法：分别检查 DNS 回答、连接与规则

验证时不要只看浏览器能否打开网页。浏览器可能使用自己的安全 DNS，也可能已经缓存了地址；网页可用并不证明它正在经过 Fake-IP 链路。建议先在本机明确指定测试 DNS，再观察应用连接。

第一步：向内核发起明确的 A 记录查询

# macOS / Linux：需要系统已安装 dig
dig @127.0.0.1 -p 1053 www.example.com A

# 同时检查 AAAA 回答，核对示例中的 IPv6 设置
dig @127.0.0.1 -p 1053 www.example.com AAAA

A 记录若位于配置的 198.18.0.0/16 地址池内，说明此次查询获得了映射地址。不要要求它固定为 198.18.0.2，也不要把返回值手动写进 hosts 文件。命中过滤列表的域名应另行测试，预期结果是上游提供的真实地址或相应 DNS 状态，而不是地址池内的回答。

第二步：清理旧缓存，再测试同一个目标

# Windows：在终端中执行
ipconfig /flushdns

# 使用 systemd-resolved 的 Linux
sudo resolvectl flush-caches

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

这些命令清理的是系统侧缓存，不保证同时清除浏览器、应用和内核自己的缓存。关闭并重新打开测试应用，必要时通过客户端清理 DNS 缓存，再使用新的连接测试。内核重启后，旧的合成地址与映射不一定仍一致，因此恢复旧浏览器连接时可能出现短暂失败。

第三步：在连接记录中核对域名与出站

查看客户端连接列表或日志，确认目标域名、命中规则和出站策略是否符合预期。需要更细信息时可短暂将 log-level 调为 debug，完成测试后恢复常用级别。分享日志前应移除订阅地址、访问令牌、节点凭据和敏感域名。

常见故障：按链路顺序定位

现象优先检查处理方向
返回 198.18 地址，所有网站都超时合成地址流量是否进入内核检查 TUN 路由、运行权限，以及其他 VPN 的路由覆盖
明确查询 1053 时提示超时DNS 模块是否启动、端口是否正确检查配置加载错误、监听地址与端口占用
只有内网服务打不开过滤规则、企业 DNS、内网路由精确排除域名，并为它配置正确的内网解析路径
浏览器正常，某个程序失败程序自己的 DNS、地址缓存与代理方式检查安全 DNS、缓存与是否绕过了流量接管
切换模式后间歇性失败应用仍持有旧地址或连接清理相关缓存，断开旧连接后重新测试

如果真实解析也失败，先查上游 DNS 是否可达，不要只扩大 fake-ip-filter。如果 DNS 正常、连接记录也出现了正确域名，但代理连接超时，则应继续排查节点连通性与出站规则。Fake-IP 位于链路前段，无法修复失效节点或错误的代理凭据。

使用浏览器安全 DNS、Android 私人 DNS 或应用内置 DoH 时，查询可能绕过内核的普通 DNS 入口。端口 53 的劫持不能直接处理所有 HTTPS 内的 DNS 请求。测试时先统一解析路径，再决定长期保留哪种 DNS 方案，避免同时改动多个变量。

适用场景与回退顺序

对已经稳定使用 TUN、需要按域名分流的桌面环境，Fake-IP 是值得优先验证的方案。对企业 VPN、复杂局域网、要求应用展示真实目标 IP 的工具，则应先确认路由和解析要求，必要时保留 redir-host。Android 的 VPN 接口通常也会与其他 VPN 应用争用，切换 DNS 模式本身不能解决接口冲突。

  1. 先做局部修正： 单个域名异常时，记录复现步骤，尝试精确过滤并验证真实解析结果。
  2. 再检查接管范围： 大量合成地址连接超时时，优先修复路由、DNS 接管与权限，而不是继续添加过滤项。
  3. 最后评估切换模式： 确认应用必须获得真实地址，或当前网络无法可靠接管合成地址时，再测试 enhanced-mode: redir-host。

切换前保存可恢复的配置，切换后重新加载并清理缓存。最终应以三项结果判断：DNS 回答符合模式预期，连接命中正确规则，日常应用与内网服务都能稳定使用。保留一份最小且可解释的配置，比持续堆叠来源不明的过滤列表更方便维护。

下载客户端