Clash Fake-IP 模式原理详解:与 Redir-Host 的区别及适用场景

Fake-IP 不是伪造公网目标，而是保留域名线索

应用访问网站时，通常先查询域名对应的 IP 地址，再向该地址建立 TCP 或 UDP 连接。传统 DNS 流程会把真实地址直接交给应用，例如将 example.com 解析成某个公网 IPv4 地址。流量进入代理内核后，内核看到的目标往往只剩这个 IP；如果规则以域名、GEOSITE 或域名后缀为条件，内核还要依靠嗅探、DNS 映射记录或额外解析恢复域名。

Fake-IP 改变的是本机 DNS 应答这一段。mihomo 收到应用对域名的查询后，从保留地址池中分配一个合成地址，默认常见范围为 198.18.0.1/16，然后把“合成地址—原始域名”的对应关系保存在内核映射表中。应用随后连接这个合成地址，流量被 TUN、透明代理或受控网络栈接回内核，mihomo 查表即可知道原始目标域名。

应用查询 www.example.com
        ↓
mihomo DNS 返回 198.18.0.23
        ↓
应用连接 198.18.0.23:443
        ↓
mihomo 查映射表得到 www.example.com
        ↓
按域名规则选择策略组与节点
        ↓
通过代理节点连接真实目标

198.18.0.0/15 是用于网络设备基准测试的保留地址段，不是互联网网站实际使用的公网地址。mihomo 常用其中的 198.18.0.1/16 作为 Fake-IP 池。合成地址只在本地代理链路中充当索引，不能被直接发送到普通网关，更不能绕过内核后继续路由。

Fake-IP 为什么通常比 Redir-Host 更直接

Redir-Host 模式仍向应用返回真实 DNS 结果。应用拿到真实 IP 后发起连接，内核再根据已有 DNS 记录、流量中的主机名或嗅探结果关联域名。其优点是网络行为接近普通系统 DNS，局域网设备、某些游戏和只认真实地址的程序更容易兼容；代价是首次查询要等待上游 DNS 返回，域名与连接之间的对应关系也可能因缓存、CDN 多地址和并发请求而变得复杂。

Fake-IP 可以立即从本地地址池应答，不必先等公网解析完成后再把结果交给应用。这里所说的“省一次解析”，准确含义是应用建立连接前不必等待真实地址解析，并不表示整个链路永远不需要 DNS。若代理服务器需要由本地解析节点域名，或最终出站需要取得目标 IP，mihomo 仍会按 proxy-server-nameserver、nameserver 和策略配置完成解析。

一次请求中真正发生了什么

1. 应用向系统 DNS 发出 A 或 AAAA 查询，常见目标端口为 UDP 或 TCP 53。
2. 系统 DNS 流量被送到 mihomo 的 DNS 模块，而不是未经控制地发往路由器或运营商 DNS。
3. mihomo 为域名分配 Fake-IP，并把映射写入内存缓存。
4. 应用连接该地址，例如 198.18.0.23:443。
5. TUN 路由或透明代理规则把连接交还 mihomo。
6. 内核恢复域名，按 DOMAIN-SUFFIX、规则集、进程规则等顺序匹配。
7. 选定 DIRECT 或代理策略后，内核才执行对应的真实出站连接。

mihomo Fake-IP 基础配置与字段解释

使用内核配置时，可以在 YAML 的 dns 段启用 Fake-IP。图形客户端若开放覆写入口，通常需要先进入「设置」→「配置」或「设置」→「参数设置」，再找到 DNS 或全局扩展配置。不同客户端的菜单名称会随版本变化，最终应以实际生成并交给 mihomo 的 YAML 为准。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

基础字段分别控制什么

• enable：启用 mihomo 内置 DNS 模块。只写 enhanced-mode 而 DNS 模块未工作，应用查询仍可能绕到系统上游。
• listen：DNS 监听地址与端口。示例使用 1053，可避免普通用户权限下直接占用 53。路由器部署时还要让 dnsmasq 把请求转发到该端口。
• enhanced-mode: fake-ip：对符合条件的域名返回合成地址。切换为 redir-host 后则返回真实解析结果。
• fake-ip-range：合成地址池。修改后要同步检查 TUN 路由、防火墙与旁路由策略，确保整个地址段都进入 mihomo。
• default-nameserver：通常填写可直接访问的 IP 地址，用于解析 DoH 或其他 DNS 服务器自身的域名，避免解析链形成循环。
• nameserver：常规域名解析上游。实际请求是否经代理还受 DNS 跟随策略与出站配置影响。
• proxy-server-nameserver：专门处理代理节点服务器域名。节点地址写成域名时，这一项可以把节点解析与普通目标解析分开。
• fake-ip-filter-mode: blacklist：列表中的域名不使用 Fake-IP，而是返回真实结果。若改成白名单逻辑，列表含义会反转，迁移配置时必须一起检查。

fake-ip-filter 应该过滤哪些域名

fake-ip-filter 的目标不是把常用网站全部排除，而是让必须获得真实地址的查询回到真实解析流程。过滤范围过大，会逐渐失去 Fake-IP 快速关联域名的价值；过滤范围过小，则可能让局域网发现、时间同步、登录探测或实时通信拿到无法直接使用的合成地址。

局域网主机与本地域名

NAS、打印机、路由器管理页和家庭自动化设备常使用 .lan、.local 或自定义内部后缀。若设备返回 192.168.1.20，应用往往需要直连这个真实局域网地址。将对应后缀加入过滤列表，并确保本地 DNS 服务器能够回答这些名称。

.local 还经常与 mDNS 配合，而 mDNS 使用组播地址和 UDP 5353，并不等同于普通单播 DNS。仅添加过滤规则未必能修复跨网段发现问题；VLAN、无线访客网络和旁路由环境还要检查组播转发与防火墙边界。

STUN、游戏与实时通信

部分游戏、语音通话和 WebRTC 程序会通过 STUN 判断公网出口与 NAT 类型。此类程序可能把 DNS 返回值直接用于 UDP 探测，或核对服务器返回的候选地址。若启用 Fake-IP 后出现语音可连接但无声音、房间匹配后掉线、NAT 类型从开放变为严格，可以先针对对应 STUN 域名过滤，而不是立即把全部 DNS 切回 Redir-Host。

游戏加速也不能简单归为“必须关闭 Fake-IP”。大量基于 HTTPS 登录、内容下载和域名分流的游戏启动器可正常使用 Fake-IP；真正需要关注的是游戏本体是否依赖 UDP、是否固定校验服务器地址，以及相关流量有没有被 TUN 完整接管。排查时应把启动器登录、资源下载、匹配服务和实时对战分开测试。

网络探测、时间同步与设备登录

• 系统连通性检测域名可能依据特定状态码或固定地址判断是否需要打开认证页面。
• NTP 常使用 UDP 123，部分设备会直接验证返回地址或绕过系统代理。
• 智能电视、游戏机和物联网设备可能只接受真实 A 记录，且不会把后续流量送入电脑上的 mihomo。
• 企业内部域名可能采用分区 DNS，同一域名在公司网络与公网返回不同结果，应交给指定内部 DNS。

过滤应按故障域名逐项增加，并记录添加原因。一个可维护的列表通常包含本地域名、确认存在兼容问题的服务域名和必要的探测域名，而不是复制数百条来源不明的规则。

TUN 模式下 Fake-IP 能否工作，取决于接管是否完整

Fake-IP 返回的地址没有公网路由意义，因此应用连接必须进入 mihomo。桌面客户端开启 TUN 后，内核通常会创建虚拟网卡并写入路由；路由器透明代理则可能依赖策略路由、nftables 或 iptables。只开 DNS 增强模式却没有接管 198.18.0.0/16，常见结果就是域名解析很快，但网页一直超时。

需要同时检查的四条链路

1. DNS 查询链路：应用查询是否真的到达 mihomo。浏览器自带安全 DNS、Android 私人 DNS和局域网手动 DNS 都可能改变路径。
2. Fake-IP 路由：198.18.0.0/16 是否指向 TUN 或透明代理处理链，而不是默认网关。
3. 规则匹配：连接恢复出的域名是否命中预期规则，最终策略组是否选择了可用节点。
4. 真实出站：节点域名、目标域名及 IPv4、IPv6 路径是否能被正确解析和访问。

如果系统启用了 IPv6，而配置中只接管 IPv4，应用可能优先使用 AAAA 结果走另一条路径。测试阶段可暂时设置 ipv6: false 缩小范围，确认 IPv4 Fake-IP 链路正常后，再补齐 IPv6 路由和 DNS 策略。长期使用时应根据本地网络是否具备稳定 IPv6 出口决定，而不是仅靠关闭选项掩盖路由问题。

用具体命令验证 Fake-IP 与规则命中

不要只凭网页能否打开判断配置。先直接查询 mihomo 的 DNS 监听端口，再查看系统路由和内核日志。以下示例假定 DNS 监听在本机 1053，混合代理端口为常见的 7890。

nslookup www.example.com 127.0.0.1
dig @127.0.0.1 -p 1053 www.example.com A
curl -x http://127.0.0.1:7890 https://www.example.com/

若 dig 返回 198.18.x.x，说明该域名进入了 Fake-IP 流程。若返回真实公网地址，检查域名是否被 fake-ip-filter 命中、当前运行配置是否仍是 redir-host，以及查询是否确实发往配置中的监听端口。

本地查询的响应时间通常应处于毫秒级。相同设备、相同网络下，可以连续执行 10 次查询并比较首次响应：例如 Fake-IP 本地应答为 2 至 8 毫秒，而真实 DoH 首查可能为 30 至 150 毫秒。数值受设备性能、上游距离和缓存影响，重点是比较同一环境中的差异，不应把某个固定延迟当成通用标准。

常见故障与定位顺序

哪些场景适合开启，哪些场景先用 Redir-Host

优先考虑 Fake-IP 的场景

• 桌面端使用 TUN 接管大多数应用，希望域名规则稳定命中。
• 订阅中包含较多域名规则、规则集和按域名划分的策略组。
• 本机上游 DNS 首次查询延迟明显，希望减少应用等待真实解析的时间。
• 需要代理不遵循系统代理设置的应用，并且 TCP、UDP 都由 mihomo 管理。
• 愿意根据局域网、游戏和实时通信情况维护精确过滤列表。

先用 Redir-Host 更稳妥的场景

• 设备只把 DNS 交给 mihomo，但实际连接没有经过 TUN 或透明代理。
• 企业内网大量依赖分区 DNS、固定真实地址和内部安全设备。
• 局域网中有许多旧设备，应用行为无法观察，也无法逐项维护过滤域名。
• 正在排查 UDP、游戏或设备发现故障，需要先建立接近普通 DNS 的对照组。
• 现有路由规则无法保证 198.18.0.0/16 始终回到 mihomo。

两种模式不是内核新旧之分，而是不同 DNS 接管策略。mihomo 接棒旧 Clash Meta 内核后继续扩展 DNS、规则集与 TUN 能力，但模式选择仍应服从网络拓扑。桌面单机、旁路由、主路由和容器环境的 DNS 入口不同，同一份配置直接复制过去不一定得到相同结果。

迁移与调整时的实用顺序

从 Redir-Host 切换到 Fake-IP 时，建议先保留原有代理规则和节点，只修改 DNS 增强模式，避免同时变更多个变量。加载配置后先查询三个目标：普通公网域名、局域网域名和已知需要过滤的域名。公网域名应得到合成地址，后两类应按设计返回真实地址。

1. 备份当前可用配置，记录 DNS 监听端口、TUN 开关和系统代理端口。
2. 启用 enhanced-mode: fake-ip，保留默认地址池或明确规划自定义范围。
3. 确认系统路由覆盖完整 Fake-IP 地址段。
4. 先加入 *.lan、*.local 等明确的本地过滤项。
5. 分别测试浏览器、即时通信、游戏、NAS 和电视盒子，不要只测试一个网站。
6. 根据日志增加最小范围的过滤规则，每条规则标注对应故障。
7. 清理过期过滤项，避免列表不断扩大后退化成近似 Redir-Host。

如果切换后问题很多，回到 Redir-Host 作为对照是有效的工程排查方式。确认故障只在 Fake-IP 出现后，再检查 DNS 入口、地址池路由、过滤列表和 UDP 接管。按链路逐层定位，比反复更换订阅、节点或整份配置更容易找到真正原因。