DNS 解析 预计阅读 10 分钟

Fake-IP 与 redir-host 对比

拆解 Fake-IP 分配虚拟地址的过程，对比它与 redir-host 在解析速度、兼容性上的差异，并说明 fake-ip-filter 的常见用法。

先区分 DNS 模式与流量接管

dns.enhanced-mode 决定 Clash 内置 DNS 如何回答域名查询。fake-ip 返回用于映射的虚拟地址，redir-host 返回上游解析得到的真实地址。它们不是规则模式、全局模式的替代项，也不决定某个连接最终走哪个代理节点。

另一层是流量接管。系统代理通常只影响遵循代理设置的程序；TUN 通过虚拟网卡和路由接管更多 IP 流量。DNS 查询是否进入内核、应用连接是否回到内核，需要分别检查。仅把配置里的模式改成 Fake-IP，并不能让所有程序自动经过代理。

  • 希望保留域名信息进行分流，且 DNS 与连接均由内核接管：优先测试 Fake-IP。
  • 应用必须取得真实 IP，或涉及局域网设备发现：先做定向过滤，再评估 redir-host。
  • 遇到超时：先定位 DNS、路由还是出站连接，不要同时改模式、节点和规则。

Fake-IP 虚拟地址如何工作

Fake-IP 的关键是“域名与虚拟地址映射”，不是把网站地址永久改写。常见地址池为 198.18.0.1/16，位于保留的基准测试地址范围内，不是网站实际部署的公网地址。这个地址必须由代理内核解释，不能当作普通目标直接发往互联网。

  1. 应用请求解析某个域名，查询进入 Clash 内置 DNS。
  2. 内核从地址池分配或复用一个虚拟地址，并保存域名映射。对符合条件的 A 查询，通常不必等待目标域名的真实 A 记录返回。
  3. 应用向该虚拟地址建立连接；TUN 等接管链路把连接交回内核。
  4. 内核依据映射恢复域名，执行规则匹配，再交给对应出站。直连通常仍需解析真实目标；代理出站是否在远端解析，取决于协议和出站实现。

为什么有时首连更快

传统路径常在建立连接前等待真实 DNS 结果。Fake-IP 可以缩短这一段等待，并使基于域名的规则更容易获得域名信息。但这不等于所有请求都更快：代理握手、TLS、远端解析和目标服务器响应仍然存在，IP 规则匹配也可能触发真实解析。

看到 198.18.x.x 的解析结果不代表网站故障，也不是实际出口 IP。直接对这个地址执行 ping，结果不能用于判断节点延迟。应使用真实业务连接，并结合内核连接面板检查规则、策略和错误信息。

redir-host 的解析路径与边界

在 redir-host 下，内置 DNS 向配置的上游解析器查询，并把真实地址交给应用。内核可记录解析产生的域名与 IP 关系，在后续流量中辅助恢复域名。但多个域名可能共享同一地址，应用也可能绕过内置 DNS，所以这种关联并不总能唯一、完整地还原原始域名。

真实地址对部分应用更友好，例如软件需要比较解析地址、直接把 IP 交给其他进程，或者设备要求访问某个局域网地址。不过，返回真实 IP 并不能保证一定直连；若流量已由 TUN 接管，仍会按规则选择出站。

对比项Fake-IPredir-host
常见 A 查询结果地址池中的虚拟 IPv4 地址上游返回的真实 IPv4 地址
建立连接前的解析可先返回映射地址，真实解析可能后移通常先等待真实解析或命中缓存
域名信息来源虚拟地址与域名的映射DNS 关联、协议提供的域名等
常见兼容性问题虚拟地址绕过接管、应用拒绝保留地址共享 IP 关联不明确、解析线路与出口不匹配
更适合的起点DNS 与连接接管完整的日常规则分流明确要求真实解析结果的应用环境

两种模式都不是防泄漏开关。应用自带的 DoH、未接管的 IPv6 流量和直接访问外部 DNS 的程序，都要单独排查。一次网页 DNS 检测显示了某个解析器，也不足以证明所有程序的查询路径相同。

Fake-IP 基础配置与接入条件

下面只展示需要合并到现有配置的 dns 段，不包含节点与代理组。保留现有订阅的其他部分；若客户端支持覆写或合并配置，应在其持久化入口修改，避免下一次订阅更新覆盖设置。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"
  • listen 的 1053 是本文示例监听端口，不是 HTTP 或 SOCKS 代理端口。只监听回环地址，不向局域网提供 DNS 服务。
  • default-nameserver 用于解析 DNS 服务器自身的域名等引导场景。这里的普通 DNS 引导查询不具备 DoH 的加密属性。
  • nameserver 是常规上游解析入口。使用 HTTPS 地址不代表全部 DNS 流量自动通过代理，实际路径仍需检查。
  • 操作系统的普通 DNS 设置通常不能直接指定 1053 端口。生产接入需要客户端的 DNS 接管、TUN DNS 劫持，或本地转发器配合，不能只填写 127.0.0.1 就认为完成接入。

如果要对照测试 redir-host，可暂时把 enhanced-mode 改为 redir-host，其余变量保持不变。Fake-IP 地址池和过滤列表不再承担分配虚拟地址的作用。先备份，再重载配置；若客户端管理 DNS，应检查生成后的运行配置确实发生了变化。

fake-ip-filter 的定向例外

在常见的默认黑名单语义下，fake-ip-filter 表示“这些域名不分配 Fake-IP，返回真实解析结果”，不是“这些域名不走代理”。是否直连仍由 rules 决定。支持过滤模式切换的 mihomo 版本还可能使用其他语义，复制列表前应确认没有额外设置白名单模式。

先列具体域名，再扩大范围

假设家庭 NAS 的域名是 nas.home.arpa，应用在收到虚拟地址后拒绝连接，可以先加入精确条目。若同一区域的设备都有同样问题，再使用内核支持的域名通配语法扩大范围。在 mihomo 的常见匹配语义中，+.home.arpa 可覆盖根域及其子域；不要把它当作所有旧内核都支持的通用写法。

dns:
  fake-ip-filter:
    - "localhost"
    - "nas.home.arpa"
    - "+.home.arpa"
    - "*.lan"
    - "*.local"

这是局部修改示例，应合并到前一段已有的 dns 中，不能在 YAML 顶层再建立第二个同名 dns 键。精确条目与覆盖它的通配条目可以按需要二选一，长期配置应删除冗余项。

过滤不负责提供内网解析答案

把 NAS 域名放入过滤列表后，上游仍需要知道它的真实地址。公共 DNS 通常不了解家庭内部域名；这时应把对应域名交给路由器或内部 DNS，必要时使用 nameserver-policy 定向解析。只有过滤而没有正确上游，问题会从虚拟地址不兼容变成域名解析失败。

.local 常用于 mDNS，依赖局域网组播。加入 *.local 只能避免相关查询被分配虚拟地址，并不等于内核会代替系统完成 mDNS 发现。打印机、投屏设备仍可能需要保持组播发现链路和局域网路由可达。

检测解析结果与连接链路

排查分三步：确认运行配置，直接查询内置 DNS，再检查应用连接。不要只看配置编辑器中的文本，也不要只凭浏览器能否打开网页得出结论。

1. 直接查询 1053 端口

在安装了 dig 的环境中，运行下面两条命令。它们明确查询回环地址的 1053 端口，不会因为系统 DNS 设置不同而误测其他解析器。

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

Fake-IP 下，未过滤域名通常应返回所配地址池中的地址；具体分配值不固定。NAS 域名只有在过滤命中且内网上游可用时，才应取得对应真实地址。查询超时先查监听状态和配置加载错误；返回真实公网地址则继续检查模式、过滤规则与客户端覆写。

2. 查看规则与出站

打开客户端连接面板，访问待测网站，查看目标域名、命中规则和使用的策略。若拿到虚拟地址却没有对应连接记录，重点检查流量是否绕过内核、是否存在路由冲突，以及应用是否在另一台未接管的设备上使用了该地址。

3. 清理旧状态后复测

切换模式后，应用可能继续使用旧缓存或已建立的连接。先退出目标应用，再清理系统 DNS 缓存并重开。Windows 可运行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可运行 resolvectl flush-caches。应用自带的 DNS 缓存未必随系统缓存一起清除。

若启用了 profile.store-fake-ip，部分内核会持久化映射。该选项有助于恢复既有映射，但不是所有超时问题的修复手段。调整地址池前，应按客户端支持的方式清理旧映射并重建连接，不要直接删除不明用途的配置文件。

按故障现象选择模式

  • 普通网页与常用应用正常：保留现有模式。没有必要为了抽象的“更快”反复切换。
  • 只有 NAS、打印机或内网域名异常：优先处理过滤、内网 DNS 和局域网路由，不急于切换整个环境。
  • 应用明确拒绝虚拟 IP：先为它实际查询的域名添加例外；依赖域名很多且难以维护时，再测试 redir-host。
  • 所有 Fake-IP 连接都超时：优先检查虚拟地址段的路由与接管。DNS 返回成功并不意味着连接已经进入 TUN。
  • redir-host 下部分站点地址不合适：检查解析出口与代理出口是否匹配，按域名设置解析策略，而不是盲目增加上游数量。

最终判断标准是可重复的业务结果：同一设备、同一节点、同一域名，分别检查解析答案、规则命中和连接是否成功。Fake-IP 更侧重通过映射保留域名并调整解析时机，redir-host 更侧重向应用提供真实地址。模式选择应服从实际接管方式与应用要求，而不是把其中一种视为所有场景的固定答案。

Clash 客户端下载