Fake-IP 模式原理：DNS 映射如何缩短手机端首包等待

先分清：DNS 回答与最终连接

手机打开一个网站时，应用通常先查询域名对应的 IP 地址，再发起连接。在支持 Clash Meta（mihomo）DNS 功能的客户端中，enhanced-mode: fake-ip 会改变查询的回答方式：内核为域名分配一个临时的合成地址，把“域名 ↔ 合成地址”的关系记在映射表里，然后把合成地址返回给应用。

应用随后连接这个地址。流量被客户端接管后，内核通过映射表找回原域名，再用域名匹配规则，并按规则选择直连或代理。合成地址是客户端内部的索引，不是网站服务器的真实地址，也不应被当作可在互联网访问的目标。

一次请求经过哪些环节

应用查询 example.com 的 A 记录；查询需要进入客户端的 DNS 处理链路。
内核返回所配置 Fake-IP 地址段中的一个地址，并保存它与 example.com 的对应关系。
应用向该地址建立连接；客户端接管连接，查回域名并执行 DOMAIN、DOMAIN-SUFFIX 等规则。
内核按选中的出站方式处理目标连接。代理出站能否按域名连接，还取决于协议、节点及客户端的具体实现。

因此，“得到 DNS 回答”与“目标已经连通”是两件事。Fake-IP 让应用较早拿到一个可用于后续匹配的地址，实际出站仍要经过规则判断、节点连接和目标服务响应。应用直接连接数字 IP、DNS 查询没有经过客户端，或后续连接未被接管时，这套域名映射流程就不能照常发挥作用。

Fake-IP 与 redir-host：真实解析放在哪一步

redir-host 通常在回答应用的 DNS 查询前，经上游 DNS 获取目标的真实 IP，再将结果返回给应用。fake-ip 则先返回合成地址，让后续被接管的连接凭映射表恢复域名。两者的关键区别不是“用不用 DNS”，而是应用等待 DNS 回答时，是否通常需要先等目标域名的真实解析结果。

观察点	Fake-IP	redir-host
返回给应用的地址	映射到域名的合成地址	上游解析得到的真实地址
域名规则的依据	合成地址对应的映射记录	DNS 查询记录；其他场景可能还依赖协议嗅探
常见取舍	应用可能更早收到 DNS 回答，但需要正确接管后续连接	应用直接获得真实地址，但 DNS 回答可能需要等待上游解析

“缩短首包等待”主要指减少应用在 DNS 阶段等待真实解析的机会，并不等于每次网页请求都更快。如果瓶颈是节点握手、丢包、目标站响应或应用自身启动，切换 DNS 模式未必改善首包时间。直连目标最终也可能需要真实解析；这部分耗时只是进入了后续处理流程，不能从总耗时中凭空消失。

对比模式时保持同一网络、同一节点与同一目标。先看应用是否能稳定建立连接，再比较等待感受；不要把 DNS 返回快误读为页面加载全过程都快。

保留地址段与映射表如何配合

mihomo 配置中常见的 fake-ip-range 示例是 198.18.0.1/16。198.18.0.0/15 属于保留用于网络设备基准测试的 IPv4 地址空间，并非普通公网网站地址。把其中一段用于本地合成地址，便于内核识别这类连接；具体地址段仍应以当前客户端配置为准。

映射表由运行中的内核维护，不是一份可永久保存的网站 IP 名册。同一个合成地址在不同运行时刻不应被假定永远对应同一域名。复制合成地址到另一台设备、把它写入长期使用的应用设置，或在客户端重启后单独拿它做连通性测试，都不能可靠反映原域名的状态。

一份最小化的 DNS 配置示例

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

这段 YAML 展示字段位置，不是适用于所有网络的完整配置。nameserver 中的地址只是可读示例：应按所在网络、订阅配置和实际可达性选择解析器。fake-ip-filter 列出不应收到合成地址的域名；具体匹配语法和客户端是否允许编辑这些字段，需以所用内核及客户端版本为准。修改时保持两个空格缩进，并先备份原配置。

仅把 enhanced-mode 改为 fake-ip 也不保证生效。应用的 DNS 请求要进入客户端，后续发往合成地址的流量也要被接管。手机端通常还涉及系统 VPN 配置、客户端的 DNS 设置和所选代理模式；某些客户端通过图形界面管理这些参数，不直接读取用户编辑的 YAML。

哪些目标适合加入过滤名单

过滤的判断标准是：目标应用是否需要拿到真实地址，或者其连接能否始终经过同一个客户端内核。不要把所有域名一股脑加入过滤名单；过滤范围越大，越多查询会回到等待真实解析的路径，原本希望减少的 DNS 等待也可能重新出现。

局域网设备：先确认域名从哪里解析

打印机、NAS、路由器常使用 printer.lan、nas.home.arpa 一类内网名称。若设备管理 App 需要真实的局域网地址，而查询收到了合成地址，可先为该设备的确切域名加过滤，再确认当前 DNS 上游能解析内网名称。过滤只改变是否返回 Fake-IP；公共 DNS 若根本不知道这台打印机的地址，单加过滤也无法让名称解析成功。

.local 名称经常通过 mDNS 在局域网发现，不一定经过普通 DNS 查询。遇到“设备列表能看到、点开却连不上”，应分别检查局域网权限、mDNS 发现、实际连接使用的域名或 IP，以及代理规则。若 App 直接访问 192.168.1.1，Fake-IP 过滤名单不会影响这条直接使用 IP 的连接。

游戏与部分 App：按具体域名排查

游戏登录、匹配和语音可能使用不同域名与 UDP 连接。先区分卡在账号登录、房间匹配还是实时通信；若只有某个域名在 Fake-IP 下异常、改用真实解析后恢复，再针对该域名加入过滤。部分 App 会缓存解析结果，改完配置后还需结束应用进程、重新打开，必要时重连客户端，让旧连接与旧缓存退出测试过程。

不要把“游戏使用 UDP”直接等同于“必须关闭 Fake-IP”。UDP 流量能否正常工作，还受客户端接管方式、节点协议、规则与服务端影响。对使用数字 IP、局域网广播或设备发现的功能，域名过滤甚至可能完全无关；这时继续添加域名只会扩大配置复杂度。

iPhone 上的排查顺序

如果切换 DNS 模式后出现无法访问、个别 App 转圈或内网设备离线，按“系统接管 → DNS 回答 → 连接规则 → 单个应用”逐层排查，比同时更换节点、订阅和 DNS 上游更容易定位原因。

确认 VPN 已连接。在 iPhone「设置」→「通用」→「VPN 与设备管理」→「VPN」查看当前连接状态，再回到客户端确认正在使用预期的配置。系统菜单名称可能随 iOS 版本变化。
确认配置已经启用。检查当前 Profile 中的 DNS 模式、Fake-IP 地址段与规则模式。订阅更新后若切到了另一份 Profile，需要在实际启用的那份配置里核对参数。
区分全部异常与单项异常。所有网站都打不开，优先检查 DNS 上游可达性、VPN 接管和节点；仅一台 NAS 或一个 App 异常，先记录它访问的域名或局域网地址。
一次只改一处。为明确的内网域名增加过滤并重连，再复测目标；若没有变化，撤回这项修改，检查局域网解析、直连规则和应用权限。

规则模式与 DNS 模式负责不同环节：前者决定请求走哪个出站，后者影响名称如何解析及返回。把某个域名写进 DIRECT 规则，不会自动保证应用拿到真实 IP；同样，把域名加入 Fake-IP 过滤，也不会自动让它走直连。需要同时满足内网真实解析与直连时，两处设置应分别核对。

只在确认“合成地址影响了目标功能”时添加过滤。保留原配置副本，记录每次改动的域名与现象，复测成功后再保留规则。