Fake-IP 与 Redir-Host 对比：DNS 增强模式原理与适用场景

两种 DNS 增强模式的核心区别

Fake-IP 与 Redir-Host 决定的是：Clash 接管 DNS 查询后，向应用返回什么地址，以及后续连接怎样关联回域名。它们不是“规则模式”和“全局模式”的替代项，也不决定节点协议。排查时应把 DNS 回答、流量接管、规则匹配和出站连接分开观察。

下文的配置片段以 Clash Meta（mihomo）为主要参照。传统 Clash、ClashX 的不同内核和各类图形客户端，支持的字段及配置覆盖方式可能不同。先在客户端的“关于”或内核信息中确认名称，再查看运行配置；不能仅凭应用名称判断配置兼容性。

比较项	Fake-IP	Redir-Host
应用收到的地址	通常是地址池分配的虚拟 IPv4 地址	上游 DNS 解析得到的真实地址
域名关联方式	利用虚拟地址与域名的映射	利用 DNS 缓存中的域名与地址关联等信息
主要适用场景	TUN 接管、希望稳定保留域名信息的连接	应用必须读取真实 DNS 地址的兼容场景
主要检查点	DNS 与连接是否交给同一内核、映射是否有效	上游解析是否正常、域名关联是否完整

Fake-IP：先分配虚拟地址，再关联域名

一次连接的处理顺序

应用查询某个域名的 A 记录，查询到达内核的 DNS 服务。
内核从配置的虚拟地址池分配地址，并保存“域名 ↔ 虚拟地址”的映射。
应用向这个虚拟地址发起连接，TUN 或其他接管机制把连接交回内核。
内核根据映射找回域名，结合规则选择出站；是否继续在本地解析真实地址，取决于规则、出站类型和协议能力。

常见的 fake-ip-range: 198.18.0.1/16 使用保留的网络基准测试地址空间。这些地址不是目标网站的公网地址，也不是节点地址。浏览器能访问页面，而系统查询显示 198.18.x.x，在这条处理链路下属于预期现象。

Fake-IP 的价值在于把“应用准备连接的地址”明确关联到域名，不必仅靠真实 IP 反推访问目标。多个域名可以共用 CDN 地址，真实地址与域名并非一一对应；虚拟地址映射能减少这种歧义。但它不保证所有请求更快，也不能绕过失效订阅、不可达节点或错误规则。

Redir-Host：返回真实地址并保留解析关联

Redir-Host 会先完成真实 DNS 解析，再把结果返回给应用。应用看到的是实际解析地址，内核则利用已观察到的 DNS 记录等信息关联域名。它不是针对每条连接都向公网执行一次 PTR 反向查询；“域名回查”在这里主要指从已有映射中恢复域名上下文。

这种方式对会检查解析结果、比较接口地址或自行处理网络连通性的应用更直观。不过，如果应用使用自己的加密 DNS、直接连接写死的 IP，或者查询未经过内核，域名关联就可能不完整。多个域名共用地址时，也不能把一个 IP 当成唯一域名标识。

改成 Redir-Host 前先确认目标

只有一台打印机或一个内部域名异常：优先为这个目标设置 Fake-IP 例外和正确的内部 DNS，不必立即切换全局模式。
应用明确要求真实 DNS 结果：可以用 Redir-Host 做对照测试，同时记录规则命中和解析结果。
节点连接超时：先检查出站地址与网络可达性。更换 DNS 增强模式未必改变节点握手结果。

TUN 模式为何常与 Fake-IP 配合

TUN 在系统网络层接收被路由进虚拟网卡的 IP 数据包，适合接管不遵循系统 HTTP 代理的应用。但 IP 数据包本身通常不直接携带原始域名。Fake-IP 映射让内核在收到虚拟目标地址时找回域名，因此常用于 TUN 下的域名规则分流。

两者仍是独立设置：开启 TUN 不代表 DNS 一定进入内核，选择 Fake-IP 也不代表所有应用连接都已接管。浏览器的安全 DNS、另一个 VPN 的路由、企业下发的 DNS 策略，都可能让查询与连接走不同路径。

mihomo 配置片段

以下仅演示 DNS 与 TUN 部分，不含节点、策略组和完整规则，不能作为可直接连接的订阅使用。合并进现有配置时应修改已有同名区块，避免出现两个 dns 或两个 tun 顶层键。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

这里的 1053 是本机 DNS 测试监听端口，不是 HTTP、SOCKS 或混合代理端口。示例中的上游 DoH 地址必须在当前网络与内核的 DNS 出站策略下可达；若不可达，应换成环境中可用的解析服务，而不是反复重启客户端。

dns-hijack 针对被 TUN 接收到、目标为指定端口的 DNS 流量。它不会自动解密浏览器通过 HTTPS 发出的 DoH 请求，也不保证捕获所有系统的本地 DNS 通信。TUN 还需要相应系统权限或服务支持；没有权限时，应先处理启动日志中的错误。

fake-ip-filter 的写法与局域网例外

在常见的默认黑名单语义下，fake-ip-filter 列出的域名不分配 Fake-IP，而是按真实解析路径返回结果。较新的 mihomo 还提供过滤模式等扩展字段；如果配置显式设置了 fake-ip-filter-mode，应先确认其含义，不能照搬默认语义。

把例外限制到实际需要的域名

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "printer.home.arpa"

printer.home.arpa 在这里是教学用局域网名称，需要替换成实际设备域名。精确名称适合单个设备；*.lan 这类条目用于相应后缀的子域名。不同内核的通配符边界可能不同，不应把这些字符串当作正则表达式，也不要未经核对便混入规则列表语法。

过滤不等于直连：不返回虚拟地址，只改变 DNS 回答方式。连接是否直连，仍由规则和出站策略决定。
过滤不等于指定 DNS：内部域名通常需要由路由器或公司 DNS 解析。必要时再使用内核支持的 nameserver-policy 配置对应解析器。
过滤不代替服务发现：.local 常涉及 mDNS。打印机发现还可能依赖多播、网卡选择和防火墙，添加域名例外不保证发现功能恢复。

切换模式后的验证步骤

一次只改一个变量。先保存当前有效配置，记录原来的增强模式、DNS 上游、TUN 状态和异常域名。图形客户端可能用界面设置或覆写文件覆盖订阅，编辑订阅原文件后，应在运行配置中确认最终值确实变化。

重载配置并检查日志：确认 DNS 监听成功、TUN 创建成功，没有端口占用或字段解析错误。
直接查询内核 DNS：在装有 dig 的 macOS 或 Linux 环境中，使用下方命令查询示例域名。
比较系统解析路径：再执行不指定服务器的查询。两次结果不一致时，先确认系统查询是否真的经过内核。
重新发起应用连接：退出相关应用后重开，必要时清理系统 DNS 缓存，避免旧的真实地址或旧虚拟地址影响判断。
查看连接记录：核对目标域名、命中规则和实际出站，而不是只看页面是否打开。

# 直接查询上文配置的内核 DNS
dig @127.0.0.1 -p 1053 example.com A +short

# 查询系统默认解析路径
dig example.com A +short

在 Fake-IP 模式下，未被过滤的 A 查询通常应返回配置地址池中的地址；在 Redir-Host 模式下，应返回上游给出的真实记录。example.com 用于说明测试方式，实际排障还需查询发生故障的域名。不要以 AAAA 查询是否出现虚拟 IPv4 地址来判断 Fake-IP 是否生效。

按系统清理 DNS 缓存

Windows 可在命令提示符中执行 ipconfig /flushdns。macOS 常用下列命令，第二条会向系统 DNS 服务发送信号；执行时按提示输入本机管理员密码。使用 systemd-resolved 的 Linux 可执行 resolvectl flush-caches，其他发行版应按实际 DNS 服务处理。

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

清理系统缓存不会自动清空浏览器内部缓存，也不会保证保留已失效的 Fake-IP 映射。切换模式后应关闭旧连接重新测试；若内核重启后频繁遇到旧虚拟地址，可检查客户端是否支持并启用了 Fake-IP 映射持久化。

常见故障与优先检查项

现象	优先检查	处理方向
解析出 198.18.x.x，但连接超时	连接是否回到同一内核，TUN 路由是否存在	排查路由排除项、并行 VPN 和过期映射
浏览器正常，某个应用失败	应用自己的 DNS、地址检查或独立网络栈	对该应用域名做精确过滤并复测
切换后仍返回真实地址	实际运行配置、过滤条目、查询服务器	先直接查询内核监听端口，再查系统路径
打印机或内部站点不可用	内部 DNS、mDNS、私网路由和防火墙	分别处理真实解析与直连规则
出现证书名称不匹配	目标域名、解析结果、门户认证或中间代理	检查证书与连接目标，不关闭证书验证

另外，ping 失败不能单独证明网站不可访问。ICMP 与浏览器的 TCP、QUIC 请求不是同一种连接，Fake-IP 的 ICMP 处理也受内核与接管方式影响。应优先用真实应用请求配合连接记录验证。

模式选择与最终核对

对于以 TUN 接管为主、希望按域名稳定分流的环境，可先使用 Fake-IP，再为确有兼容需求的域名增加小范围例外。对于依赖真实 DNS 回答的应用，可用 Redir-Host 对照验证；切换后仍应保留正确的 DNS 上游与域名规则。

最终只需核对四件事：DNS 查询交给谁，应用获得什么地址，连接由谁接管，规则选择哪个出站。四个环节都有证据，再决定改增强模式、改过滤列表还是修路由。需要查阅代理端口和规则概念，可继续查看使用文档与术语表。