进阶原理 预计阅读 12 分钟

Fake-IP 与 redir-host 区别：mihomo DNS 增强模式原理与适用场景

从 DNS 解析流程讲清 Fake-IP 如何分配虚拟地址、为何能减少解析延迟，以及 fake-ip-filter 的用途和不适合启用的应用类型。

DNS 增强模式改变了什么

在 mihomo 配置中，dns.enhanced-mode 决定内置 DNS 如何处理地址查询，以及后续连接如何关联域名。常见取值为 fake-ip 和 redir-host。它不是代理协议，也不等于规则模式、全局模式或 TUN 开关。

理解两种模式，先区分三个动作：应用查询域名、操作系统发起连接、内核按规则选择出站。DNS 返回什么地址，只决定其中一部分流程。最终走直连还是代理，仍由规则、策略组和可用出站共同决定。

Fake-IP：用虚拟地址保留域名关联

从查询到建立连接

  1. 应用向已被接管的 DNS 查询某个域名的 A 记录。
  2. mihomo 从配置的地址池中分配虚拟 IPv4 地址，并保存“域名与虚拟地址”的映射。
  3. 应用收到该地址后发起连接。连接必须再次进入同一个能够识别映射的内核。
  4. 内核根据虚拟地址找回域名，执行规则匹配，再通过选中的出站访问目标。

例如，地址池配置为 198.18.0.1/16 时，应用可能收到该网段内的地址。这个网段来自用于基准测试的保留地址空间，并不是目标网站的公网地址，也不是代理服务器地址。不要把它手动添加为网站的固定 IP。

Fake-IP 的关键不是伪造网站内容，而是在连接到达内核之前保留域名身份。多个网站即使共用一个 CDN 真实地址，也可以通过各自的虚拟地址关联到不同域名，便于执行域名规则。

为什么可能减少解析等待

返回虚拟地址通常不需要先等待目标域名的真实 A 记录。对于能携带域名的代理出站，内核可以把域名交给远端继续处理，从而减少客户端侧等待真实解析的环节。这里减少的是部分前置等待，并不是让所有访问都跳过 DNS。

  • 命中直连：本机通常仍需得到真实目标地址，才能建立直连。
  • 命中 IP 类规则：规则判断可能需要解析，具体取决于规则类型、顺序及是否使用 no-resolve。
  • 代理节点使用域名：节点自身也需要解析，不能靠目标网站的 Fake-IP 映射解决。
  • 首次握手与远端网络：TCP、TLS、节点负载和远端 DNS 仍可能成为主要耗时。

因此，DNS 查询更快不等于网页一定更快。不要把节点延迟测试结果当作 DNS 耗时，也不要仅凭浏览器第一次打开的体感判断模式优劣。

redir-host：先返回真实地址

使用 redir-host 时，内置 DNS 查询上游并向应用返回真实解析结果。内核可以利用 DNS 缓存中的域名与地址关系辅助处理后续连接，但共享 IP、多域名解析到同一地址等情况会增加关联的不确定性。嗅探可以提供额外域名线索，但不是所有协议都能被识别。

这里的“真实地址”指上游 DNS 返回的地址，不保证它一定可达、最优或没有受到网络环境影响。上游选择、分流 DNS、缓存和出站路径仍然需要独立检查。

比较项Fake-IPredir-host
应用收到的地址地址池中的虚拟地址；过滤项除外上游返回的真实解析地址
域名关联主要依靠虚拟地址映射可依靠 DNS 缓存及其他域名线索
返回地址前的等待通常无需等待目标真实解析通常需要真实解析结果或已有缓存
应用兼容性依赖应用能接受虚拟地址更接近常规 DNS 地址行为
连接接管要求连接到虚拟地址后必须回到内核真实地址本身不依赖虚拟映射

最小配置与 DNS 接管边界

下面是用于解释字段的 DNS 片段，不是完整订阅配置。它监听本机 127.0.0.1:1053，指定一个明文上游，并对少数本地域名返回真实解析结果。上游地址应按实际网络与隐私需求调整。

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:
    - "localhost"
    - "+.lan"
    - "+.local"
    - "+.home.arpa"
  nameserver:
    - 223.5.5.5

listen 只是监听地址，不会自动把系统 DNS 改到这里。常规系统 DNS 设置通常只接受服务器 IP，不提供端口输入；不能把 127.0.0.1:1053 原样填入只接受 IP 的字段。需要通过客户端的 DNS 接管、TUN DNS 劫持或本地转发，让查询到达该监听服务。

TUN 与系统代理的差别

TUN 用于接收系统路由送来的 IP 流量，DNS 增强模式用于处理 DNS，两者职责不同。TUN 配置中的 dns-hijack 可以接管匹配的 DNS 流量，例如常见配置项 any:53 面向普通 DNS 请求；TCP DNS 需要按相应语法单独考虑。端口 443 上的 DoH 不会仅因为配置了 53 端口劫持就自动变成内置 DNS 查询。

仅开启系统 HTTP 代理时，部分应用会把目标域名直接交给代理，另一些应用仍在本机解析。此时看到真实 IP 不一定是配置失败。反过来，若应用拿到了 Fake-IP，却通过未被接管的路径直接连接虚拟地址，就可能超时。

fake-ip-filter：只对必要域名例外处理

fake-ip-filter 控制哪些域名采用不同的地址返回方式，不是广告过滤表，也不是出站规则。在上面的 blacklist 模式中，命中列表的域名不分配 Fake-IP，而是返回真实解析结果。若改用 whitelist，列表语义会反转，不能照搬黑名单内容。

  • localhost 是精确域名示例。
  • +.lan 表示该域名及其子域名范围，不是普通字符串包含匹配。
  • +.home.arpa 可用于家庭网络内部域名，但仍需有能回答该域名的 DNS。
  • +.local 只能影响实际进入内置 DNS 的查询；mDNS 通常使用 UDP 5353，多播发现不由这个列表完整处理。

把域名加入过滤表，不会自动让它直连。若目标是局域网服务，还要确认对应规则选择 DIRECT、路由可以到达私有地址，并通过合适的 DNS 上游或 nameserver-policy 获取内部记录。过滤表只解决“返回虚拟地址还是真实地址”这一层。

不建议为了排除一个故障就加入过宽的后缀，或直接让所有域名返回真实地址。先从连接记录中找到实际失败的域名，再添加最小范围的例外。订阅中已有过滤项时，也要确认客户端的覆写方式是合并还是替换。

不适合直接启用的应用与网络

依赖真实 IP 的工具

网络诊断、IP 归属地判断、把解析地址写入访问控制名单的程序，可能把 Fake-IP 当成真实服务器地址。此时结果失去原本含义。需要诊断真实地址时，可针对目标域名使用真实解析，或在受控测试中切换到 redir-host。

局域网发现与企业内部服务

NAS、打印机、投屏和企业内部域名往往依赖本地 DNS、多播、广播或专用路由。返回真实地址只是必要条件之一。企业 VPN 的分流 DNS、TUN 路由与私有地址段发生冲突时，还需要调整接管范围，不能单靠过滤表解决。

把解析结果交给其他设备的程序

若程序在本机解析后，把地址发送给另一台设备建立连接，另一台设备通常没有对应 Fake-IP 映射。部分点对点、媒体或控制类应用可能存在这种行为，但不能据此认定所有游戏、视频或 UDP 应用都不兼容。应以实际域名、连接路径和错误日志判断。

另外，硬编码真实 IP 的应用没有进行域名查询，Fake-IP 过滤自然无从生效。此时应检查 IP 规则、UDP 支持、路由与防火墙，而不是继续添加域名例外。

验证与排障：按查询、映射、出站检查

  1. 确认运行配置：检查当前加载的 Profile 与最终生效的 dns.enhanced-mode。远程订阅更新可能覆盖直接修改的文件，优先使用客户端提供的持久覆写机制。
  2. 直接测试监听：若系统安装了 dig，可执行下面的命令，绕过系统默认 DNS 直接询问示例监听端口。
  3. 检查连接记录：访问同一域名，查看内核是否记录到连接、是否关联到域名、命中了哪条规则，以及最终出站是什么。
  4. 检查旁路解析：如果直接查询正常而应用行为不同，检查浏览器安全 DNS、应用内置 DoH、系统缓存和其他 VPN。
  5. 单项对照：先仅为故障域名添加过滤；仍失败时再对照 redir-host。每次只改一个变量，保留可恢复副本。
dig @127.0.0.1 -p 1053 example.com A

在上述 Fake-IP 配置中，未命中过滤的 A 查询应返回配置池中的地址；切换为 redir-host 后应得到上游实际结果。该命令只验证 DNS 监听与返回值，不能单独证明 TUN 接管或代理出站正常。

切换模式后，应用可能仍保存之前的虚拟地址。Windows 可用 ipconfig /flushdns 清理系统 DNS 缓存，但浏览器与应用缓存还可能需要重启应用才能释放。若只是清掉映射却继续让应用使用旧 Fake-IP，新的连接仍可能失败。

需要比较速度时，应保持相同网络、节点、目标域名和出站规则，分别记录冷缓存与热缓存结果。例如每种模式各做 10 次查询，将首次结果单独列出，再比较其余结果的中位数。这是测试方法，不是本站的性能测量结论；DNS、连接建立和页面加载应分开记录。

模式选择与配置保留

  • 优先考虑 Fake-IP：DNS 和业务流量能够稳定进入同一个 mihomo 内核，需要清晰的域名关联，并且应用不依赖真实解析地址。
  • 优先考虑 redir-host：工作流程需要真实 IP，兼容性优先，或当前网络无法保证虚拟地址连接回到内核。
  • 采用局部过滤：大部分应用正常，只有少量内部域名或特定程序失败，并且已定位到真实地址需求。

若希望重启后尽量保留映射，可检查配置中的 profile.store-fake-ip。持久化可以减少映射丢失带来的问题，但不能修复错误路由，也不能保证切换配置、改变地址池或清理数据后旧地址仍有效。最终应以运行配置、DNS 返回值和连接记录三者一致为准。

下载Clash