先分清：DNS 增强模式不是代理模式

dns.enhanced-mode 决定内核如何处理 DNS 查询，以及如何把后续连接关联到域名；mode: rule 决定连接按什么方式分流。两者不是同一个开关。选择 Fake-IP，不代表所有流量都走代理；选择 redir-host，也不代表连接必然直连。

本文以 Clash Meta（现称 mihomo）的常见配置字段为例。旧版 Clash 与不同客户端的支持范围可能不同，编辑前先在客户端的内核信息中确认实际使用的是哪个内核。图形界面里的开关还可能覆盖配置文件，因此最终应核对内核实际加载的配置，而不是只看订阅原文。

  • DNS 层：处理域名查询，向应用返回地址。
  • 流量入口：系统代理、TUN 或路由器透明接管，把连接送到内核。
  • 规则层：按 rules 的顺序选择直连、代理组或拒绝连接。

Fake-IP 必须与流量接管配合。应用拿到合成地址后，如果连接没有回到持有对应映射的内核，就无法按预期访问目标。

Fake-IP 原理：先返回合成地址，再按域名建立连接

假设应用查询 www.example.com。在 Fake-IP 模式下，内核可以从配置的地址池中分配一个合成 IPv4 地址，并保存“合成地址 → 域名”的映射。应用随后连接这个地址，内核接住连接，再找回原始域名并执行分流规则。

  1. 应用把 DNS 查询交给 Clash 或 mihomo 的 DNS 服务。
  2. 内核返回地址池中的地址，例如 198.18.0.2；具体分配结果不固定。
  3. 应用向该地址发起连接，TUN 等入口把连接送回同一内核。
  4. 内核恢复域名，匹配规则，再按选中的出口建立实际连接。

为什么常见地址是 198.18 开头

198.18.0.0/15 是用于网络设备基准测试的特殊用途地址段，不是目标网站的公网地址。配置中常见的 198.18.0.1/16 位于这个范围内。它也不是普通家庭局域网常用的 RFC 1918 私有地址段。若企业网络或实验环境恰好使用相同范围，应先检查路由冲突。

解析更快，不等于所有请求都省掉解析

对可使用 Fake-IP 的查询，内核通常不必等待目标真实地址返回，就能给应用合成地址。这能减少应用在 DNS 阶段的等待，也能保留明确的域名信息。但直连出口最终仍要获得真实地址；代理出口是否在远端解析，还取决于节点协议和连接方式。首次网页加载也受握手、线路和服务器响应影响，不能承诺固定提速比例。

redir-host 区别：返回真实地址，兼容依赖 IP 的应用

redir-host 会通过上游 DNS 查询真实地址并返回给应用，同时利用 DNS 查询记录维护域名与地址的关联。后续连接进入内核时，可以利用这些关联辅助域名规则匹配。但多个域名共用同一地址、应用使用独立 DNS 或 DNS 缓存来源不同，都可能让关联不够明确。

比较项 Fake-IP redir-host
应用收到的地址 地址池中的合成地址，过滤项除外 上游解析得到的真实地址
DNS 应答等待 通常可先返回合成地址 需要真实解析结果或已有缓存
域名关联 通过合成地址映射恢复域名 依赖 DNS 记录等信息辅助关联
常见兼容问题 应用检查真实 IP、合成地址未被接管 解析结果不合适、域名关联不完整
优先尝试场景 流量接管完整的日常浏览与规则分流 依赖真实解析结果的工具或兼容性排查

redir-host 不是“隐私模式”，Fake-IP 也不自动保证所有 DNS 都经过代理。是否使用 DoH、DoT，上游请求从哪个出口发出，应用是否绕过系统 DNS，是另外几组问题。启用浏览器安全 DNS 后，查询可能不再进入内核的 DNS 服务；不要仅凭 enhanced-mode 的值判断是否存在 DNS 泄漏。

Fake-IP 配置：先确认 DNS 入口，再设置过滤名单

下面是用于说明字段关系的 mihomo DNS 片段，合并到已有可用配置中使用，不是一份包含节点和规则的完整配置。若原文件已有 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
    - 119.29.29.29
  • listen：本例只在本机回环地址的 1053 端口接收查询，不会自动修改系统 DNS，也不向局域网设备开放监听。
  • enhanced-mode：设为 fake-ip 才启用该增强模式。
  • fake-ip-range：指定合成地址池。它不是代理节点地址，也不是 DNS 上游地址。
  • fake-ip-filter：本例按默认的黑名单语义使用，匹配项改为返回真实解析结果。
  • nameserver：这里使用两个具体的普通 DNS 上游作演示，应按所在网络的可达性和隐私需求调整。

部分新版 mihomo 支持用 fake-ip-filter-mode 改变过滤逻辑。若已有配置显式使用 whitelist，名单的含义会反过来，不能直接套用本文的排除列表。跨内核迁移时先核对字段支持情况。

fake-ip-filter 只决定 DNS 是否返回合成地址，不等于添加 DIRECT 规则。需要直连的目标，还要在 rules 中安排合适的分流规则。

TUN 的 DNS 劫持与监听端口分开理解

支持相应字段的 mihomo 配置，可通过 tun.dns-hijack 将常规 DNS 流量交给内核处理。例如下面的片段表达接管 UDP 与 TCP 的 53 端口查询；它不意味着能够直接解密应用自己的 DoH。TUN 的启用权限、路由和客户端覆盖设置仍需单独确认。

tun:
  enable: true
  auto-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

不要把这段配置与系统代理视为同一种入口。浏览器使用 HTTP 代理时可能直接把域名交给代理，未必通过本机 DNS；TUN 则常常需要接管应用先解析、再连接 IP 的完整路径。

游戏、局域网设备与 fake-ip-filter 的使用边界

局域网 NAS、打印机：先让本地域名解析正确

如果路由器通过普通 DNS 提供 nas.home.arpa，可排除该名称，并让查询交给实际知道这个记录的路由器 DNS。假设路由器地址确实为 192.168.1.1，可在原有 DNS 段内合并以下条目：

  fake-ip-filter:
    - 'localhost'
    - '*.lan'
    - '*.local'
    - 'nas.home.arpa'
  nameserver-policy:
    'nas.home.arpa':
      - 192.168.1.1

这里的路由器地址必须与当前网络一致。过滤名单不会凭空补出本地 DNS 记录。直接通过 192.168.1.20 访问 NAS 时没有域名查询，修改 Fake-IP 过滤通常没有作用，应转查私网路由、TUN 绕行与防火墙。

.local 还常用于 mDNS 发现。把 *.local 放入过滤名单，不会自动转发 mDNS 组播，也不能修复跨网段的打印机发现。需要把“设备发现失败”与“已知地址无法连接”分开排查。

游戏与语音：按异常域名排除，不按类别全部直连

部分游戏、语音或连通性检测工具会检查 DNS 返回的地址，或者把解析结果交给另一台设备使用。这类流程可能不适合合成地址。先从日志中找出登录、匹配、语音或 STUN 相关的实际查询域名，再按精确名称加入过滤名单；不要凭服务名称猜一长串域名。

  • 登录正常，语音失败：同时检查节点的 UDP 能力、UDP 分流及 NAT 条件，过滤 DNS 不会补齐 UDP 支持。
  • 只有某个检测失败：先只排除该检测域名，保留其他流量的 Fake-IP 行为。
  • 手机经电脑共享代理：确认手机连接合成地址时仍经过生成映射的电脑内核，不能只把 DNS 指向电脑。

不建议直接添加 '*' 来“解决所有兼容问题”。在黑名单语义下，这会让所有匹配查询避开 Fake-IP，失去原本的地址映射机制，也让后续排查难以判断究竟是哪一项导致问题。

切换模式后的验证步骤与常见误判

  1. 备份并单独改一个变量。先保存当前配置，仅调整 DNS 模式或一个过滤项，不同时修改节点、规则和 TUN 路由。
  2. 重新加载配置。检查日志是否有 YAML 缩进、未知字段或端口占用错误；加载失败时，内核可能仍使用旧配置。
  3. 检查 DNS 应答。对本文监听地址可执行下面的查询，确认请求确实发给内核。
  4. 清理旧解析状态。关闭并重新打开目标应用，必要时清理系统 DNS 缓存；旧连接与应用自带缓存不会因为编辑文件立即消失。
  5. 检查实际连接。在客户端连接记录中查看目标域名、命中规则与出口，再判断问题发生在解析、分流还是连接阶段。
dig @127.0.0.1 -p 1053 www.example.com A

# Windows PowerShell：清理系统 DNS 缓存
Clear-DnsClientCache

# Windows 命令提示符：同类操作
ipconfig /flushdns

dig 需要系统已安装相应工具。该命令显式指定 1053 端口；直接运行普通 nslookup 通常测试的是系统配置的 DNS，并不一定是本文的监听服务。对于未被过滤的域名，在 Fake-IP 模式下看到地址池中的 A 记录是正常现象，不应把它当成公网解析被篡改的证据。

改成 redir-host 后，为什么仍连接 198.18 地址

常见原因是应用还保存着旧地址，或客户端没有把新配置交给内核。先核对实际运行模式，再关闭旧连接、清理缓存并重试。如果重启内核导致 Fake-IP 映射丢失，而应用仍持有旧合成地址，也可能连接失败；支持的内核可通过 profile.store-fake-ip 持久化映射，但它不能代替正确的流量接管。

IP 类规则是否仍然有效

Fake-IP 不等于禁用 IP 规则。内核在需要时可以解析真实目标地址来完成相关匹配，具体还受规则顺序、缓存与 no-resolve 等参数影响。不要拿合成地址直接判断目标所属地区，也不要给整个 Fake-IP 地址池加直连规则来修复网站访问。

选择建议：日常使用优先稳定，兼容问题局部处理

日常网页访问、流量入口明确且 DNS 能进入内核时，可以先尝试 Fake-IP。若只有 NAS、游戏登录或某项检测异常，优先添加少量有依据的过滤项，配合正确的本地 DNS 与规则。只有在应用确实依赖真实地址、或者当前环境难以完整接管合成地址流量时，再对照测试 redir-host。

最终判断标准不是 DNS 查询单项耗时，而是目标应用能否稳定完成完整流程：域名解析、规则命中、连接建立和数据传输。保留一份可用配置，记录修改字段与复现步骤，比反复同时切换多个开关更容易定位问题。初次配置可先阅读订阅导入与配置教程；遇到连接异常，再查阅疑难手册。