进阶配置 预计阅读 12 分钟

Fake-IP 模式原理详解：mihomo DNS 增强模式与适用场景

讲清 Fake-IP 如何用保留地址段换取更快的解析与更准的分流，与 redir-host 的差异、fake-ip-filter 的写法，以及不适合开启的场景。

Fake-IP 的工作链路：域名、合成地址与实际连接

Fake-IP 是 mihomo DNS 的一种增强模式，通过 dns.enhanced-mode: fake-ip 启用。它向应用返回一个合成的 IPv4 地址，并在内核中保留“域名与合成地址”的映射。这个地址不是网站服务器的真实地址，也不是代理节点地址；它相当于交给应用的连接索引。

常见配置使用 198.18.0.1/16 作为分配范围。它属于为网络基准测试保留的 198.18.0.0/15 地址空间，不是供网站在公网发布服务的普通地址段。使用时仍要检查企业网络或实验网络是否已经占用该地址空间，不能仅因它是保留地址就假定没有冲突。

  1. 应用查询 example.com，查询进入 mihomo 的 DNS 服务。
  2. mihomo 为该域名分配一个池内地址，并保存映射。应用拿到的可能是 198.18.0.2，具体分配值不固定。
  3. 应用连接这个合成地址；连接必须再次进入同一个 mihomo 内核。
  4. 内核根据映射恢复域名，执行规则匹配，再按选中的直连或代理出站建立实际连接。

解析更快与分流更准，分别指什么

减少等待上游 DNS 的机会

对于可由本地分配合成地址的查询，mihomo 不必先等上游返回目标网站的真实 IPv4 地址，便能回答应用。若后续走支持传递域名的代理出站，目标域名还可以交由远端解析。这减少的是部分链路中的 DNS 等待，不代表节点延迟、下载带宽或服务器响应速度随之改善。

若规则最终选择 DIRECT，建立直连通常仍需要真实地址。被过滤的域名、某些查询类型以及其他需要真实解析结果的处理也仍会使用上游 DNS。因此不能把 Fake-IP 理解为“所有访问都不再查询 DNS”，也不宜给出适用于所有网络的固定提速百分比。

保留域名上下文，便于匹配域名规则

透明接管连接时，系统最初交给内核的往往只是目标 IP。Fake-IP 映射让内核能恢复原始查询域名，再匹配 DOMAIN、DOMAIN-SUFFIX 等规则。例如 DOMAIN-SUFFIX,example.com,Proxy 可匹配该域名及其子域名；其中 Proxy 必须是配置中实际存在的代理或代理组名称。

  • 规则仍从上往下执行，较早命中的规则可能先决定出站。
  • 应用直接连接硬编码 IP 时，没有对应的 DNS 查询，Fake-IP 无法凭空恢复域名。
  • 应用绕过 mihomo 自行使用加密 DNS 时，内核不一定能得到映射；嗅探功能可补充部分域名信息，但不是所有协议都能嗅探。

Fake-IP 与 redir-host 的区别

redir-host 会向应用返回上游解析得到的真实 IP，并尝试利用 DNS 记录关联域名与连接。它不是“关闭 DNS”，也不是一个出站模式。两种 DNS 增强模式都能配合规则模式工作，区别主要在于应用收到的地址，以及内核如何保留域名信息。

比较项 Fake-IP redir-host
应用收到的 IPv4 地址 符合条件时返回地址池内的合成地址 返回实际解析得到的地址
域名关联方式 通过合成地址与域名的映射恢复 依据 DNS 记录关联，共用 IP 等情况可能增加歧义
初始 DNS 等待 部分查询可直接本地回答 通常需要等待上游回答，缓存命中除外
兼容性关注点 应用是否要求真实地址，连接是否回到同一内核 真实解析的质量、DNS 缓存与域名关联是否完整
局域网应用 可能需要为内部域名添加过滤与专用解析 仍需配置能解析内部域名的 DNS

选择时先看需求。需要透明接管并主要依赖域名规则时，可优先测试 Fake-IP；需要向应用暴露真实地址，或已有软件无法兼容合成地址时，可使用过滤规则，必要时再切换到 redir-host。切换 DNS 模式后应清理旧缓存并重建连接，否则测试结果可能混入旧地址。

最小配置：先验证 DNS，再接管系统流量

下面是用于本机验证的 mihomo 配置片段，不是完整订阅。它只在回环地址的 1053 端口提供 DNS 服务，不会自动修改系统 DNS，也不会自动开启 TUN。应合并到现有配置的对应字段，避免在同一个 YAML 文档中重复声明 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-mode: blacklist
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"
    - "+.home.arpa"
  nameserver:
    - 1.1.1.1
    - 9.9.9.9
  • listen 控制 DNS 监听位置。系统 DNS 设置通常不能填写自定义端口，不能直接把“127.0.0.1:1053”当成普通 DNS 服务器地址填入系统界面。
  • ipv6: false 仅用于收窄本例的 DNS 测试范围，不等于关闭操作系统 IPv6，也不是所有部署都应采用的设置。
  • nameserver 是示例上游，需确认当前网络能够访问。企业内部域名通常还需要内部 DNS，不能期待公共解析器返回内部地址。
  • fake-ip-filter-mode 以当前支持该字段的 mihomo 为前提。旧 Clash 分支的字段支持不同，应先确认客户端所用内核，并查看配置加载错误。

桌面客户端可能通过“覆写”或“扩展配置”生成运行配置，订阅更新也可能覆盖直接编辑的内容。修改后应在客户端提供的运行配置查看入口核对最终 dns 段，并在日志页确认配置加载成功。不要把编辑器里保存成功等同于内核已采用新设置。

fake-ip-filter 写法：返回真实地址，不代表直连

在上述 blacklist 模式中，命中 fake-ip-filter 的域名不使用 Fake-IP，而改为真实解析。"localhost" 用于指定名称；"*.lan" 用于匹配对应子域名；"+.home.arpa" 可覆盖 home.arpa 及其子域名。带星号的字符串应加引号，避免被 YAML 当成其他语法处理。

先添加具体域名，再考虑整类后缀

假设 NAS 使用 nas.home.arpa，应用又要求获得真实内网地址，可将它加入过滤列表。同时还需让该域名交给家庭路由器的 DNS 解析。仅添加过滤项不会自动发现正确的内部 DNS；若上游仍是公共解析器，结果可能仍然是域名不存在。

.local 常用于 mDNS，而 mDNS 与普通单播 DNS 的发现机制不同。把 "*.local" 写入过滤列表，只解决“不要合成地址”这一层问题，不能保证跨网段发现打印机、投屏设备或其他局域网服务。

过滤列表与出站规则分开维护

把一个域名加入过滤列表，不会自动生成 DIRECT 规则。它依然要按 rules 判断出站。反过来，添加直连规则也不等于必须禁用该域名的 Fake-IP：内核可以先恢复域名，再解析真实地址并直连。

TUN、系统代理与 DNS 劫持怎样配合

Fake-IP 是 DNS 层的行为，TUN 是流量进入内核的一种方式，系统代理则是告诉遵循该设置的应用使用本机代理端口。三个概念不能互相替代。尤其是浏览器通过 HTTP 代理传递目标域名时，目标解析可能由代理链路处理，不一定经过浏览器本地的 Fake-IP 查询。

  • 系统代理：适合会读取系统代理的应用。未读取该设置的游戏、命令行工具或后台服务，可能仍按原有网络路径连接。
  • TUN：通过虚拟网络接口接管符合路由条件的流量。还需核对路由、排除项以及 DNS 查询是否进入内核。
  • DNS 劫持：例如 TUN 配置中的 dns-hijack 可处理所指定的 DNS 流量，但端口 53 的劫持不等于拦截所有 DoH、DoT 或应用内置解析。

多网卡、VPN 与企业安全软件并存时，路由优先级可能使合成地址的连接走错接口。另一个常见问题是本机和路由器各运行一个内核：DNS 映射存在路由器上，连接却交给本机内核。两套独立映射不能自然互通，应让 DNS 回答与连接处理落在同一套接管链路中。

基础入口可参考系统代理设置与规则模式说明。排查时每次只改变一个变量：先验证 DNS，再验证接管，最后核对规则与代理组选择。

验证方法：查询结果、连接日志与缓存

第一步：直接查询 mihomo 的监听端口

使用前面的本机测试配置时，可执行以下命令。Windows 使用 nslookup，安装了 dig 的 Linux 或 macOS 环境可使用第二条。测试域名不应在过滤列表内。

nslookup -port=1053 example.com 127.0.0.1

dig @127.0.0.1 -p 1053 example.com A

若回答落在配置的 198.18.0.0/16 范围内，说明该次查询经过了 Fake-IP 分配。若返回真实公网地址，应检查过滤列表、最终运行配置与查询目标。若超时，则先查 DNS 是否启用、监听端口是否被占用以及内核是否成功启动。

第二步：观察实际应用连接

在接管链路建立后访问同一域名，查看客户端“连接”页或日志页中的目标域名、命中规则与出站链。查询命令获得合成地址，只能证明 DNS 分配有效；应用能够连接并按预期命中规则，才说明整个链路有效。不要把对合成地址执行 ping 的结果当作网页可用性的判据。

第三步：清理缓存后复测

Windows 可通过 ipconfig /flushdns 清理系统 DNS 缓存；使用 systemd-resolved 的 Linux 可执行 resolvectl flush-caches。浏览器和应用还可能维护独立缓存与长连接，需要关闭相关连接或重启应用。清理系统缓存并不保证清空所有应用缓存。

mihomo 的 profile.store-fake-ip: true 可用于持久保存 Fake-IP 映射，但它不能修复错误路由，也不会让不同设备共享映射。若重建映射、变更地址池或切换模式，应同时处理应用残留的旧地址，避免“应用仍持有旧地址，内核已无对应记录”的状态。

不适合直接开启的场景与回退顺序

部分软件会把 DNS 结果当作真实服务地址使用，例如将地址写入信令、交给另一台设备连接，或据此判断是否位于局域网。此时合成地址可能被传到无法访问该映射的设备。企业内网、实验网络与某些游戏的连接流程也值得单独测试，而不是整机开启后只检查浏览器。

  1. 只有一个应用异常：确认它使用哪些域名、是否自带 DNS、是否直接连接 IP；先对确有兼容问题的域名添加过滤项。
  2. 只有内网服务异常：检查内部 DNS、域名过滤、私网路由与出站规则。地址解析正确但仍无法访问时，继续排查路由与访问权限。
  3. 所有应用同时异常：检查合成地址是否进入同一内核、TUN 路由是否生效，以及是否与其他 VPN 冲突。
  4. 必须让应用获得真实地址：备份运行配置，切换 enhanced-mode: redir-host，重新加载配置，再清理缓存、重建连接并验证规则。

最后需要区分隐私边界：Fake-IP 不等于加密 DNS，也不保证所有 DNS 查询都通过代理发送。上游协议、DNS 出站策略、应用自带解析与直连规则都会影响实际路径。判断是否符合预期，应结合查询、路由与日志证据，而不是仅看客户端中“Fake-IP”开关是否打开。

Clash下载