Clash Fake-IP 模式是什么:DNS 返回假地址的原理与适用场景

Fake-IP 不是错误地址，而是一张临时号码牌

应用访问网站时，通常先向 DNS 查询域名对应的 IP 地址，再向该 IP 发起 TCP、UDP 或 QUIC 连接。传统流程中，DNS 必须先给出真实地址，连接才能继续。Fake-IP 改变的是这一步：Clash 或 mihomo 的内置 DNS 先从保留地址池分配一个地址，并把“域名—假地址”的对应关系写入内存。

常见地址池是 198.18.0.0/16。这段 IPv4 地址由 RFC 2544 留作网络设备基准测试，不应在公网路由。mihomo 配置常写成 198.18.0.1/16，可分配约 65534 个地址。浏览器看到的可能是 198.18.0.23，但它并不会真的去公网寻找这台主机。

当应用随后连接 198.18.0.23:443 时，Clash 内核从映射表取回原始域名，例如 www.example.com。规则引擎此时可以直接按域名匹配 DOMAIN、DOMAIN-SUFFIX、GEOSITE 等规则，再决定走代理、直连还是拒绝。若流量走代理，域名还可交给代理链路处理；若规则要求直连，内核再通过配置的 DNS 服务器取得真实地址。

一次访问中发生了什么

浏览器查询 api.example.com 的 A 记录。
Clash DNS 从 Fake-IP 地址池返回 198.18.0.23，同时保存映射。
浏览器向 198.18.0.23:443 建立连接。
系统代理、透明代理或 TUN 模式把这条连接交给内核。
内核恢复域名，按规则组选择 DIRECT、PROXY 或其他策略。
需要真实 IP 时，由内核或代理服务器完成解析，再连接目标站点。

“省一次 DNS 往返”指的是应用不必等待公网权威解析完成，就能先拿到本地应答并发起连接。真实解析并未凭空消失，而是被延后、合并，或移动到代理一侧完成。最终延迟仍受 DNS 服务器、代理节点和目标网络影响。

Fake-IP 与 Redir-Host 的核心差异

Redir-Host 是另一种常见的增强 DNS 模式。它会先完成真实 DNS 查询，再把真实 IP 返回给应用。应用连接真实 IP 后，内核尝试结合 DNS 映射、连接信息或域名嗅探恢复域名。它的结果更接近普通网络，因此对局域网设备、少数严格检查 DNS 结果的应用更友好。

Fake-IP 则优先保留域名。规则判断发生时，内核已经知道这条连接最初访问哪个域名，不必只依赖目标 IP，也较少受到同一 IP 承载多个站点的影响。CDN 场景尤其明显：数百个域名可能共享一个边缘地址，仅看 IP 很难准确区分业务。

比较项	Fake-IP	Redir-Host
返回给应用的地址	通常为 198.18.0.0/16 内的保留地址	DNS 查询得到的真实地址
域名规则识别	通过映射直接恢复，通常更稳定	依赖 DNS 映射或嗅探补充
首次 DNS 应答	本地快速分配地址	等待上游 DNS 返回结果
局域网兼容性	部分域名需加入过滤列表	通常更接近系统原有行为
适合场景	TUN、透明代理、精细域名分流	简单系统代理、特殊设备兼容

两种模式没有绝对高低。桌面设备使用 TUN 接管流量，并且规则以域名为主时，Fake-IP 通常更省心。路由器旁挂、局域网发现、打印机控制或旧应用较多时，可以先测试过滤规则；若仍有异常，再切换 Redir-Host 做对照。

mihomo 中的 Fake-IP 配置方法

下面示例适用于 mihomo 1.19 系列常见配置结构。不同图形客户端可能把选项拆到界面中，但最终都要生成对应 YAML。修改前先复制当前配置；订阅配置会在更新时覆盖本地内容，应优先使用客户端提供的覆写、Mixin 或扩展脚本功能。

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-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "localhost.ptlogin2.qq.com"
    - "+.pool.ntp.org"
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.12.12.12/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query

逐项理解配置

enable: true：开启内置 DNS。只写 enhanced-mode 而未开启 DNS，不会产生预期效果。
listen: 127.0.0.1:1053：只在本机 1053 端口监听。普通用户进程直接监听 53 端口可能受权限限制，也可能与系统 DNS 服务冲突。
ipv6: false：不向应用返回 AAAA 结果。网络具备稳定 IPv6、规则也覆盖 IPv6 时可以启用，但应同时检查直连和代理链路。
enhanced-mode: fake-ip：选择 Fake-IP 增强模式。若写成 redir-host，DNS 会返回真实地址。
fake-ip-range：指定 IPv4 地址池。一般保留默认值，不要改成家庭局域网使用的 192.168.0.0/16 或 10.0.0.0/8。
fake-ip-filter-mode: blacklist：列表内域名跳过 Fake-IP，返回真实解析结果。这是最常用的行为。
nameserver：处理普通域名解析。示例使用 DoH，连接端口通常为 443。
proxy-server-nameserver：专门解析代理节点服务器的域名，避免解析节点地址时出现循环依赖。

验证 Fake-IP 是否生效

macOS 或 Linux 可使用 dig 指定本机 DNS 端口。Windows 可用支持自定义端口的 DNS 工具，或者临时把监听端口调整为可供系统查询的 53 端口后测试。以下命令不会修改系统设置：

dig @127.0.0.1 -p 1053 www.example.com A

# 预期答案类似：
# www.example.com.  1  IN  A  198.18.0.2

如果返回公网真实 IP，先检查实际加载的配置中是否仍是 redir-host，再检查该域名是否命中 fake-ip-filter。如果查询超时，使用 lsof -nP -iUDP:1053 或 ss -lunp 查看端口是否监听。图形客户端还应确认当前运行配置，而不是只查看订阅原文件。

mihomo 开启 external-controller: 127.0.0.1:9090 后，也可通过控制接口查询 DNS。未设置控制接口密钥时，示例请求如下：

curl "http://127.0.0.1:9090/dns/query?name=www.example.com&type=A"

若控制接口配置了 secret，请求必须附带对应的 Bearer 凭据。9090 控制端口不应直接暴露到公网，家庭局域网共享也应设置访问限制。

fake-ip-filter 应该怎么写

fake-ip-filter 的作用是让特定域名绕过假地址分配，直接取得真实 DNS 结果。需要过滤的通常不是“打不开的网站”，而是依赖真实地址、局域网地址或特殊 DNS 记录工作的服务。列表过大反而会削弱 Fake-IP 的域名映射优势。

适合加入过滤列表的类型

局域网名称：*.lan、+.local、路由器管理域名和 NAS 自定义域名。
时间同步：部分 NTP 客户端只接受直接解析出的 UDP 目标，可过滤 +.pool.ntp.org。
网络连通性检测：某些系统通过固定域名和返回内容判断是否需要弹出酒店、机场或校园网认证页。
设备发现与投屏：打印机、电视、音箱和投屏设备可能依赖 mDNS、单播 DNS 与局域网地址配合。
明确校验 DNS 地址的应用：少量程序会把 DNS 结果与实际连接地址比较，保留地址可能触发异常。

dns:
  enhanced-mode: fake-ip
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "router.asus.com"
    - "miwifi.com"
    - "+.pool.ntp.org"
    - "time.windows.com"
    - "time.apple.com"

*.lan 一般用于匹配子域名，+.local 在 mihomo 域名匹配语法中可覆盖根域及其子域。不同内核版本对通配表达式的支持可能不同，迁移旧版 Clash 配置时应查看运行日志。最稳妥的排查方式是先写完整域名，确认恢复后再扩大匹配范围。

白名单模式不是通用优化项

mihomo 支持把 fake-ip-filter-mode 设置为 whitelist。此时逻辑反转：只有列表内域名使用 Fake-IP，其他域名返回真实地址。这适合希望逐步启用 Fake-IP 的特殊环境，但容易造成规则行为不一致，不建议仅为了“减少假地址”随意开启。

dns:
  enhanced-mode: fake-ip
  fake-ip-filter-mode: whitelist
  fake-ip-filter:
    - "+.example.com"
    - "+.example.net"

调整过滤列表时，一次只增加一到两项。保存配置、重载内核、清理系统 DNS 缓存，然后复现问题。macOS 可执行 sudo dscacheutil -flushcache，Windows 可执行 ipconfig /flushdns。浏览器还可能保留独立 DNS 缓存，完全退出浏览器后再测试更可靠。

哪些场景更适合 Fake-IP

TUN 模式接管整机流量

TUN 会创建虚拟网卡，在网络层接收比系统代理更广的流量。命令行工具、部分游戏启动器以及不读取系统代理的应用，也能进入内核。Fake-IP 返回的保留地址必须被内核接住，因此它与 TUN、透明代理或路由器重定向配合最自然。

如果只开启 Fake-IP，却没有开启系统代理、TUN 或透明转发，应用可能直接向 198.18.0.0/16 发包，最终表现为连接超时。此时 DNS 看似正常，真正缺少的是流量接管链路。排查时应同时查看 DNS 查询日志和连接日志。

规则主要按域名组织

配置中大量使用 DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOSITE 或规则集时，Fake-IP 可以在连接建立阶段保留域名上下文。相比只拿到 CDN IP 后再猜域名，这种方式更容易解释规则为什么命中。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

GEOIP,CN,DIRECT,no-resolve 中的 no-resolve 表示不要仅为匹配该条 IP 规则额外触发 DNS 解析。Fake-IP 环境下，这能减少不必要查询，但是否使用要结合前面的域名规则顺序。规则从上到下匹配，首条命中后即停止。

希望降低本地 DNS 污染影响

应用先收到本地 Fake-IP，不直接依赖运营商 DNS 返回的目标地址。实际解析可交给加密 DNS 或代理链路，因此错误应答和解析路径泄漏更容易控制。不过，Fake-IP 不是单独的安全开关：若 nameserver 仍指向不稳定的明文 DNS，或者代理节点域名解析配置错误，问题仍可能存在。

Fake-IP 不适用或需要谨慎的场景

局域网设备和企业内网域名较多

企业内部 DNS 可能把 git.company.test 解析到 10.20.0.15，家庭 NAS 也可能依赖路由器下发的搜索域。若所有查询都送往公共 DoH，内网域名会直接解析失败；即使 Fake-IP 成功分配地址，后续也找不到真实服务。

这种情况应通过 nameserver-policy 为内网后缀指定内部 DNS，而不是把所有域名一股脑加入过滤列表。例如内部 DNS 位于 10.20.0.53：

dns:
  enhanced-mode: fake-ip
  nameserver:
    - https://223.5.5.5/dns-query
  nameserver-policy:
    "+.company.test":
      - 10.20.0.53
  fake-ip-filter:
    - "+.company.test"

旁路由没有完整回收保留网段

路由器给客户端返回 Fake-IP 后，必须确保发往 198.18.0.0/16 的流量回到运行 mihomo 的设备。策略路由、iptables 或 nftables 规则漏掉 UDP，常见表现是网页能打开，但 QUIC、语音或游戏连接失败。此时应检查 TCP 与 UDP 是否都进入 TUN 或透明代理链路。

应用依赖真实 DNS 答案

网络诊断工具、DNS 管理工具以及少数反作弊或设备发现程序，可能需要看到真实 A、AAAA、PTR 或 SRV 记录。对这类程序，全局切换 Redir-Host 往往过重；优先把明确域名加入过滤列表，或让该程序的 DNS 查询绕过 Clash。

常见故障与定位顺序

DNS 返回 198.18 地址，但网页打不开

确认系统代理或 TUN 已开启，而不只是启用了内置 DNS。
检查连接日志中是否出现目标域名；完全没有日志通常表示流量未进入内核。
检查 198.18.0.0/16 是否被其他 VPN、虚拟机软件或公司路由占用。
临时关闭 QUIC，使用 TCP 443 对照测试，判断是否只漏接 UDP。
把目标域名加入 fake-ip-filter；若立即恢复，再继续检查应用兼容性。

只有局域网域名打不开

先用内部 DNS 直接查询，例如 dig @192.168.1.1 nas.lan。若能得到 192.168.1.20，说明内部解析正常。接着为该后缀设置 nameserver-policy，并加入过滤列表。还要确认规则中私有网段位于代理兜底规则之前：

rules:
  - 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
  - MATCH,PROXY

订阅更新后设置被还原

订阅提供的是远端配置快照。客户端更新订阅时，本地直接编辑的 YAML 可能被覆盖。应在客户端的覆写功能中维护 DNS 段，例如进入「设置」→「配置」→「全局扩展」或对应的 Mixin 页面。具体名称随客户端版本变化，但原则相同：订阅保存节点与规则，本地扩展保存设备相关的 DNS、TUN 和监听端口。

切换模式后仍看到旧结果

DNS 缓存可能存在于操作系统、浏览器和 Clash 内核三层。先重载配置或重启内核，再清理系统 DNS 缓存，最后完全退出浏览器。Fake-IP 记录的 TTL 常被设置得较短，但已建立的连接不会因为切换 DNS 模式立即重建。

配置结论：先保证流量接管，再优化 DNS

Fake-IP 的价值不在于返回一个特殊地址，而在于把域名信息稳定保留到规则匹配阶段。它让 TUN 和透明代理更容易按域名分流，也能把真实解析放到更合适的网络路径上。看到 198.18.x.x 并不代表 DNS 故障，前提是连接随后确实进入 Clash 内核。

实用配置可以从默认地址池、黑名单过滤模式和两个可靠 DNS 上游开始。局域网域名交给 nameserver-policy，必须取得真实地址的域名放进 fake-ip-filter。出现问题时按“DNS 是否监听—查询是否返回—连接是否接管—规则是否命中—真实解析是否成功”的顺序检查，比反复切换节点更快。