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

DNS 增强模式决定返回什么地址

Mihomo 的 dns.enhanced-mode 主要影响内置 DNS 如何回答查询，以及后续连接如何关联到域名。它不等于代理模式，也不决定所有流量是否经过代理。Rule、Global 与 Direct 是另一层设置；TUN 则负责接入系统流量。

先抓住核心区别：fake-ip 通常向应用返回一个由内核分配的合成 IPv4 地址；redir-host 向应用返回上游 DNS 解析得到的真实地址。两者都需要正确的 DNS 接入路径。仅在配置中启用 DNS，并不会自动让系统或浏览器把查询交给内核。

对比项	Fake-IP	redir-host
应用取得的 IPv4	通常是合成地址	上游解析的真实地址
域名与连接关联	通过合成地址映射还原	依赖 DNS 映射等信息，必要时配合嗅探
回答查询的前置工作	可先分配地址，不必等待目标真实地址	通常需要取得解析结果
典型兼容问题	应用校验 IP、地址绕过内核	共享 IP 导致域名关联不唯一

Fake-IP 的连接过程与性能边界

合成地址不是目标服务器地址

常见配置使用 198.18.0.1/16 作为 Fake-IP 地址范围。它位于为网络基准测试保留的 198.18.0.0/15 范围内，不是可在公网正常路由的目标地址，也不是 RFC 1918 定义的私有地址段。内核将分配的地址与请求域名建立映射。

应用查询一个域名的 A 记录，查询进入 Mihomo DNS。
内核为域名分配合成地址，并把该地址返回给应用。
应用尝试连接合成地址，连接必须再次进入持有映射的内核。
内核还原域名，执行规则匹配，再按选中的直连或代理出口建立连接。

合成地址不能脱离对应映射单独使用。如果应用把地址交给未经过内核的进程，或者 TUN 没有接住这段地址的流量，连接就可能失败。关闭客户端后仍有程序访问 198.18.x.x，往往意味着应用或系统还缓存着旧结果。

减少 DNS 等待，不代表所有访问都更快

Fake-IP 可以把真实解析推迟到确有需要时。若命中域名规则，且所用代理协议支持传递域名，目标解析可能由远端处理；若选择 DIRECT，内核仍需要取得真实地址。IP 类规则也可能触发解析，因此规则结构会影响实际收益。

它主要减少连接前的部分 DNS 等待，不会直接缩短物理链路距离，也不会提高代理服务器带宽。游戏延迟、视频吞吐和丢包率仍取决于出口、路由与协议。本文没有给出实测加速比例，避免把解析阶段的变化当成整个连接的性能结论。

redir-host 的适用条件

在 redir-host 下，应用拿到真实解析地址，内核会维护 DNS 相关映射，用于辅助识别连接的域名。这种方式与依赖真实 IP 的应用更接近传统网络行为，但域名关联不一定唯一：多个域名可能共用同一个 CDN 地址，同一域名也可能返回多个地址。

适合先尝试的情况：应用需要检查目标 IP、向其他设备传递地址，或在多个网络栈之间共享解析结果。
不能自动解决的情况：上游 DNS 返回错误地址、内网 DNS 无法到达、UDP 出口不可用，或连接根本没有进入内核。
仍需留意的情况：应用自带加密 DNS，导致内核没有观察到普通 DNS 查询；域名规则此时可能缺少匹配依据。

嗅探可以从部分 TLS、HTTP 或 QUIC 流量中补充域名信息，但并非所有协议都能提供可用域名。加密方式、客户端实现与嗅探配置都会影响结果。不要把开启嗅探视为修复全部域名分流问题的通用开关。

fake-ip-filter：只排除必要域名

fake-ip-filter 控制哪些域名不使用合成地址。在 blacklist 模式下，命中的域名走真实解析；未命中的域名仍可分配 Fake-IP。Mihomo 还支持其他过滤模式，因此阅读配置时应同时查看 fake-ip-filter-mode，不能只看列表名称。

下面展示一个 DNS 配置片段。监听地址采用 127.0.0.1:1053，只供本机访问；它不是一份完整的 TUN 配置，也不会自动修改系统 DNS。现有配置如果已有 dns:，应合并字段，避免重复顶层键。

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:
    - '+.home.arpa'
    - '+.lan'
  nameserver:
    - 1.1.1.1
    - 9.9.9.9

过滤合成地址不等于直连

+.home.arpa 表示匹配该域名及其子域名。这里用它说明家庭网络域名的处理；.lan 则是一些本地网络采用的后缀。过滤列表只改变 DNS 回答方式，不会自动添加 DIRECT 规则，也不会自动把查询送往路由器。

因此，内网访问通常需要三件事同时成立：返回真实地址、向正确的内网 DNS 查询、把连接路由到可达的内网出口。只做第一件事，公共 DNS 仍可能返回不存在的域名错误。

局域网与企业内网的 DNS 配置

假设一个家庭网络使用 192.168.50.53 提供内网 DNS，设备名称为 nas.home.arpa。在前述 dns: 内，可以增加以下字段。这个地址仅用于说明网络结构；应用前必须换成当前网络实际可达的 DNS 地址。

  nameserver-policy:
    '+.home.arpa':
      - 192.168.50.53

还应在已有 rules: 中，把局域网规则放在最终兜底规则前。例如下面两条分别覆盖域名与该示例网段；不要因此覆盖原有订阅规则或删除已有策略组。

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,PROXY

最后一行假设配置中已经存在名为 PROXY 的策略组；实际名称必须与现有配置一致。no-resolve 的作用是避免仅为了这条 IP 规则而主动解析域名，不会让一个本来无法解析的内网域名变得可用。

企业 VPN 与 .local 名称要分开处理

企业 VPN：确认内网 DNS 的路由经过企业 VPN。若 TUN 与企业 VPN 同时接管路由，需要检查网段冲突、路由优先级及客户端提供的绕过设置。
短主机名：输入 nas 可能依赖系统搜索域。优先用完整名称测试，避免把搜索域缺失误判成 Fake-IP 故障。
.local：常用于 mDNS，通常涉及 UDP 5353 和组播。添加普通 DNS 过滤项不等于打通 mDNS；应检查局域网发现机制与组播路径。
跨网络切换：离开公司或家庭网络后，原来的内网 DNS 可能不可达。保留按域名分流的边界，避免把全部 DNS 查询都交给内网服务器。

游戏与 TUN 模式的选择顺序

普通网页能访问而游戏无法登录，并不能直接证明 Fake-IP 不兼容。游戏可能同时使用 HTTPS 登录、UDP 对战、语音与局域网发现。系统代理通常不能覆盖所有这些流量，TUN 能接入更多 IP 流量，但也需要权限、路由及 UDP 出口支持。

先看连接是否进入内核。打开客户端连接列表或日志，再启动游戏。若完全没有对应连接，优先检查接入方式，而不是修改过滤列表。
区分登录与对战。登录失败时记录认证域名；进入房间后断线时检查 UDP、出口策略与 NAT 行为。两类问题可能来自不同路径。
确认是否依赖真实地址。若日志显示特定域名获得合成地址后失败，可只将该域名加入过滤列表，保持出口和其他条件不变再测试。
最后做模式对照。临时切换到 redir-host，重新加载配置并清理缓存。只有同一网络、同一出口下的对照，才有助于判断模式兼容性。

使用 TUN 时，检查 DNS 劫持配置是否接入了实际查询。常见 DNS 使用 53 端口，但浏览器的 DoH 往往通过 HTTPS 的 443 端口发送；只接管 53 端口不能拦住全部加密 DNS。需要测试时，可暂时关闭浏览器安全 DNS，并记录原设置，测试结束后再按需求恢复。

验证结果与恢复步骤

先验证内核 DNS，再验证系统接入

如果采用前面的本机 1053 端口示例，可在装有 dig 的 macOS 或 Linux 环境执行以下命令。第一条观察普通域名是否得到合成地址；第二条检查内网域名是否由正确的 DNS 返回真实地址。内网名称应使用当前网络实际存在的记录。

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

这些命令直接查询指定端口，能证明内核 DNS 的回答，却不能证明系统和浏览器也在使用它。随后还要在实际应用发起连接，并核对客户端日志里的域名、目标地址、命中规则与出口。若直接查询正常而浏览器行为不同，优先检查浏览器 DNS、系统缓存和应用缓存。

切换模式后清理旧状态

保存现有配置备份，单次只改 DNS 模式或一个过滤项。
重新加载配置；客户端若提供 DNS 缓存或 Fake-IP 映射清理操作，按其界面执行。
Windows 可使用 ipconfig /flushdns 清理系统 DNS 缓存。
macOS 可执行 sudo dscacheutil -flushcache，再执行 sudo killall -HUP mDNSResponder；这些操作不保证清除浏览器自身缓存。
完全退出并重启受影响应用，避免旧连接和旧地址干扰对照结果。

日常以域名规则分流、且连接能完整经过内核时，可以先使用 Fake-IP。遇到少数内网或应用兼容问题，优先按域名增加例外并配置正确的解析器。只有在应用持续依赖真实 IP、例外难以维护或对照测试明确指向模式差异时，再考虑整体采用 redir-host。

继续检查接入路径，可查阅连接检查步骤；需要区分 DNS、规则与维护设置，可阅读DNS 配置说明。判断标准始终是查询去了哪里、返回了什么，以及连接最终由哪个出口处理。