1. DNS 模式与流量接管是两层配置

dns.enhanced-mode 决定内核如何回答 DNS 查询；系统代理与 TUN 决定应用连接怎样进入内核。两者不能互相替代。开启 Fake-IP，不代表系统所有 DNS 请求已经被接管；开启 TUN，也不代表浏览器自带的加密 DNS 一定会交给内核解析。

本文以使用 mihomo 内核的 Clash 客户端为讨论对象。旧版 Clash、不同分支内核以及客户端覆写功能可能存在差异。操作前先保存当前配置，记录内核版本，并核对运行时配置中的 dns 字段，不要只看订阅原文件。

  • 系统代理：应用如果向 HTTP 代理发送域名，内核可以直接获得目标名称，不一定依赖本机 DNS 的 Fake-IP 映射。
  • TUN：接收应用发出的 IP 数据包。DNS 接管和映射表对恢复原始域名尤其重要。
  • DNS 监听：例如 127.0.0.1:1053，只是内核接受查询的位置。系统仍需通过合适的转发或劫持路径把查询送到这里。

判断配置是否生效，要分别检查“DNS 查询去了哪里”和“后续连接去了哪里”。只观察客户端主开关，无法确认这两条路径一致。

2. Fake-IP 地址分配与域名回查流程

Fake-IP 的核心是建立“域名与合成 IP”的映射。应用询问某个域名的 IPv4 地址时，内核可以从 fake-ip-range 指定的地址池分配一个地址并返回，而不必先等待该域名的真实 A 记录。常见地址池为 198.18.0.1/16，位于保留的基准测试地址空间，不是网站的公网地址。

  1. 应用查询 example.com，查询进入 mihomo DNS。
  2. 内核返回池内的一个合成地址，并保存该地址对应 example.com 的映射。具体分配值由运行状态决定，不应写死。
  3. 应用连接这个合成地址，连接通过 TUN 等接管路径进入同一个内核实例。
  4. 内核查映射表恢复域名，再按规则选择直连或代理出站。
  5. 直连通常仍需解析真实目标地址；代理出站若支持传递域名，则可把域名交给远端处理。具体行为还受规则、节点协议和相关 DNS 配置影响。

为什么有时能减少等待

对于能够直接按域名分流、再把域名交给代理出站的连接，本地不需要先完成目标站点的真实 IP 查询。因此，较慢或受干扰的本地解析不再必然阻塞首次建连。但 Fake-IP 不会消除节点握手、远端解析或服务器响应时间，也不能保证所有网站都更快。

为什么映射丢失会断网

合成地址只在持有映射的内核中有意义。若应用缓存了旧地址，而内核重启后映射没有保留，后续连接可能无法还原域名。切换客户端、切换 DNS 模式或让流量进入另一台网关，也可能造成同类问题。修复时应重新发起 DNS 查询，而不是给合成地址添加一条普通直连规则。

3. redir-host 的解析时机与规则匹配差异

redir-host 通常先向上游 DNS 查询，再把真实地址返回给应用。内核会利用经过自身 DNS 的查询结果维护域名与 IP 的关联，辅助后续连接恢复域名。它的兼容性优势是应用看到的仍是真实地址，但真实地址与域名并非总是一一对应。

比较项Fake-IPredir-host
返回给应用的 A 记录通常是地址池内的合成地址通常是上游返回的真实地址
首次查询的等待分配合成地址通常无需等待目标真实解析通常需要等待上游解析完成
域名恢复依据合成地址对应的映射DNS 查询记录与真实 IP 的关联
共享 IP 的影响不同域名可分别建立映射多个域名共用 IP 时，关联可能存在歧义
应用自行使用加密 DNS可能绕过合成地址分配可能绕过内核 DNS 关联记录
局域网服务兼容性常需为内部域名设置过滤返回真实内网地址通常更直接

规则本身也会改变解析时机。即使启用 Fake-IP，执行需要目标真实 IP 的规则时，内核仍可能触发解析。IP-CIDR 等规则上的 no-resolve 可用于避免为该条规则主动解析域名，但不是“禁止整个连接解析”的总开关。规则顺序、是否已知真实 IP，以及其他规则的行为都需要一起检查。

如果程序直接连接一个 IP，没有先向内核查询域名，两种 DNS 模式都不能凭空获得可靠的原始名称。流量嗅探可能从部分协议握手中提取域名，但它不是 DNS 映射的等价替代，也不覆盖所有加密协议。

4. Fake-IP 与 DNS 泄漏的关系

DNS 泄漏通常指查询没有沿预期的解析路径发送，例如本应走指定解析器的查询被发往接入网络提供的 DNS。Fake-IP 可以减少部分代理域名的本地真实解析，却不是泄漏防护总开关；redir-host 也不必然泄漏。是否泄漏取决于查询的接管范围、上游协议和出站选择。

  • 浏览器安全 DNS：浏览器直接通过 HTTPS 查询外部解析器，可能跳过系统 DNS。排查时可暂时关闭该功能，再比较结果。
  • 普通 UDP/TCP DNS：端口通常是 53。TUN 的 DNS 劫持可覆盖符合条件的请求，但 HTTPS 443 或 TLS 853 上的加密查询不能简单按 53 端口规则处理。
  • IPv6：只验证 A 记录不够，还需检查 AAAA 查询、IPv6 路由和应用连接。IPv4 Fake-IP 地址池不能证明 IPv6 路径也已接管。
  • 引导与节点解析：加密 DNS 服务的域名、代理节点服务器域名可能另有解析路径，需要检查 default-nameserver、proxy-server-nameserver 等字段。

使用 DoH 可以加密到解析器之间的查询，但不自动保证该连接走代理，也不代表解析器看不到域名。测试网站显示某个 DNS 运营方，只能说明它观察到的解析出口；还应结合内核日志与网络抓包，核对目标解析器和实际出站。

5. fake-ip-filter 配置与局域网例外

fake-ip-filter 用于决定哪些域名不按常规 Fake-IP 方式返回。下面示例显式使用 mihomo 的 blacklist 过滤模式：命中列表的域名返回真实解析结果，其余域名仍可分配合成地址。若旧内核不支持 fake-ip-filter-mode，应先查对应版本文档，不要直接套用字段。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.home.arpa"
    - "router.home.arpa"
  nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.lan": 192.168.1.1
    "+.home.arpa": 192.168.1.1

这是字段关系示例，不是可直接覆盖全部配置的订阅文件。192.168.1.1 假设为实际负责内部域名解析的路由器；使用前必须替换为当前网络的内部 DNS 地址。示例公网解析器使用普通 DNS，便于观察流程，不代表加密或代理解析方案。listen 也不会自动修改系统 DNS。

过滤、解析策略、出站规则各管一层

  • fake-ip-filter：决定命中域名是否避开合成地址，不负责指定直连。
  • nameserver-policy：为内部域名选择能回答它的 DNS。公网解析器通常不知道企业或家庭网络的私有记录。
  • rules：决定连接的出站。内部服务即使获得真实 IP，仍需有适合的直连规则和可达路由。

例如可在宽泛代理规则之前放置下面两条规则。它们只处理出站选择，不能替代 DNS 策略，也不要为了套用示例而删除已有规则：

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - DOMAIN-SUFFIX,lan,DIRECT

局域网服务为什么容易受影响

NAS、打印机、投屏和部分游戏发现机制会校验目标是否位于本地网段，或把解析结果传给其他设备。若收到 198.18.0.0/16 内的地址，应用可能拒绝连接；另一台没有同一映射的设备也无法使用该地址。优先过滤实际使用的内部域名，不要一开始就把全部域名排除。

.local 常用于 mDNS，涉及多播发现，而不仅是普通单播 DNS。把 *.local 加入过滤列表并不会自动恢复 mDNS。遇到投屏设备不可见，应同时检查局域网访问权限、多播转发、TUN 路由和防火墙。通过路由器分发 DNS 给其他设备时，还必须保证这些设备访问合成地址的流量也经过持有映射的网关。

6. 验证 DNS 回答与连接接管

先用明确的监听地址验证内核 DNS，再检查系统默认查询路径。以下命令适用于提供对应工具的系统，查询端口 1053 必须与运行配置一致：

# Windows：直接查询内核 DNS
nslookup -port=1053 example.com 127.0.0.1

# macOS / Linux：直接查询内核 DNS
dig @127.0.0.1 -p 1053 example.com A

# 检查内部域名是否返回真实内网地址
dig @127.0.0.1 -p 1053 router.home.arpa A
  1. 核对回答：未过滤的域名在 Fake-IP 模式下应按配置返回池内地址；过滤后的内部域名应得到内部 DNS 提供的真实地址。若查询超时，先检查监听和内核启动状态。
  2. 核对系统路径：再运行不指定服务器的 nslookup example.com，或用正常应用访问。直查内核成功，不代表系统查询已经进入内核。
  3. 核对连接记录：在客户端连接页面或日志中查看域名、匹配规则与出站。能解析但连不上时，检查流量是否进入同一内核以及规则是否选错节点。
  4. 单独检查 IPv6：查询 AAAA 记录，观察应用实际使用的地址族。不要仅因 A 记录正常就认定整个 DNS 路径正常。

排查期间可把 log-level 临时设为 debug，完成后恢复常用等级，避免长时间记录大量域名。分享日志前应去除订阅地址、令牌、节点凭据和内部主机名。

7. 切换模式与故障处理顺序

如果主要需求是 TUN 下的域名规则分流，且 DNS 与连接都能进入同一内核，可优先评估 Fake-IP。如果大量应用需要真实 IP、内部服务复杂，或受限环境中难以保证合成地址的接管路径，可比较 redir-host 的兼容性。选择依据是数据路径，不是模式名称。

症状优先检查处理方向
返回合成地址后连接超时TUN 路由、内核映射是否一致修复接管路径，重新查询 DNS
公网正常，NAS 域名失败过滤列表、内部 DNS、直连规则为具体内部域名配置例外
重启后部分应用断连应用缓存的旧合成地址关闭旧连接，清理缓存后重试
改完订阅后模式又恢复客户端 DNS 覆写与订阅更新机制在实际生效的配置层修改
只有浏览器结果不同浏览器加密 DNS 与自身缓存统一测试路径后再比较模式

每次只改变一个变量

  1. 备份配置，记录当前 enhanced-mode、DNS 上游和 TUN 状态。
  2. 只切换 DNS 模式，保留同一节点、同一规则和同一测试域名。
  3. 应用配置后关闭旧连接，清理系统及应用 DNS 缓存。Windows 可执行 ipconfig /flushdns；浏览器和其他应用可能仍需单独重启。
  4. 依次测试公网域名、内部域名和实际业务应用，记录失败发生在查询、规则匹配还是建连阶段。

不要把永久关闭 IPv6、批量过滤所有域名和切换节点同时作为一次修复。一次改变多个条件，会丢失定位依据。字段含义可继续查阅配置字段参考，接管路径可结合入门指南核对。

最终配置应满足三个条件：查询交给预期的解析器，连接进入预期的内核，规则选择预期的出站。Fake-IP 与 redir-host 都只是这条链路中的 DNS 工作方式；把这三项分别验证，才能区分解析故障、路由故障和代理节点故障。