进阶配置 预计阅读 12 分钟

Fake-IP 模式如何保留域名信息：DNS 映射、适用场景与排除项

沿 DNS 查询与连接建立过程解释虚拟地址映射，说明 Fake-IP 的适用条件、局域网兼容问题及 fake-ip-filter 的配置边界。

一、Fake-IP 与真实地址解析的区别

启用 Fake-IP 后，查询某个网站的 A 记录时，应用可能拿到 198.18.0.2 一类地址，而不是网站服务器的公网 IP。这通常是内核主动生成的虚拟地址，不应仅凭这个结果判断 DNS 故障。它的用途是让后续连接携带一个可回查的标记，由内核还原这次访问对应的域名。

普通 DNS 解析返回真实地址后，应用可能只向网络栈提交目标 IP。多个域名共用 CDN 地址时，仅凭这个 IP 很难确定原始域名。Fake-IP 则在 DNS 应答阶段建立“域名与虚拟地址”的关联，连接进入同一个内核后，可以通过映射找回域名，再进行规则匹配和出站处理。

  • Fake-IP 不是代理节点：它是本机处理链路中的地址标记，不代表远端服务器的位置。
  • Fake-IP 不是 DNS 加密：上游使用 UDP、DoH 还是 DoT，是另一层配置。
  • Fake-IP 不等于全局代理：在 mode: rule 下，连接仍按规则进入直连或代理等目标。

198.18.0.0/16 位于为网络基准测试保留的 198.18.0.0/15 地址空间内，不是网站的真实公网地址，也不是普通家庭局域网地址段。如果设备所在网络已经使用这一范围，应先处理路由冲突，而不是继续叠加接管规则。

二、从 DNS 查询到出站连接的五个步骤

理解 Fake-IP 的关键是分开看两条路径：DNS 查询进入哪里，以及拿到地址后的连接进入哪里。只有它们能关联到同一份有效映射，虚拟地址才有意义。

  1. 应用发起查询。例如浏览器请求 example.com 的 A 记录，查询经系统解析器、DNS 转发或 TUN 的 DNS 接管进入内核。
  2. 内核分配虚拟地址。若域名符合 Fake-IP 处理条件，内核返回地址池中的一个地址，并保存映射。本文使用 198.18.0.2 解释流程，实际分配值不固定。
  3. 应用建立连接。应用向这个虚拟地址的目标端口发起连接，例如 HTTPS 的 443 端口。
  4. 内核回查域名并匹配规则。内核接收到连接后，利用映射识别 example.com，域名规则便有了可匹配的信息。
  5. 按选定出站处理。直连一般需要取得真实目标地址；代理出站可能把域名交给远端解析，也可能在本地解析，取决于协议、节点选项与内核行为。
应用查询 example.com
  → 内核 DNS 返回虚拟地址
  → 应用连接虚拟地址:443
  → 同一内核回查得到 example.com
  → 匹配规则
  → 直连或代理出站

因此，“DNS 已返回 Fake-IP”只能证明查询路径的一部分成功，不能证明连接已经被接管。若应用拿到了虚拟地址，却绕过内核直接发送数据，普通网络并不知道应该把它送到哪个网站，表现往往就是连接超时。

为什么有域名映射仍可能发生真实 DNS 查询？

Fake-IP 可以让应用先取得虚拟应答，但不保证整个连接过程完全不查真实 IP。直连出站、需要目标 IP 的规则判断、代理服务器自身的域名解析等，都可能触发解析。规则是否带有 no-resolve、内核是否支持对应规则选项，也会影响处理过程，不能把“减少部分等待”理解为“取消所有 DNS 查询”。

三、启用前检查 DNS 与连接接管范围

Fake-IP 更适合需要透明接管、并希望保留域名规则匹配信息的环境，例如已经正确配置路由和 DNS 接管的桌面 TUN。它不是所有应用联网问题的默认修复项。

使用方式 域名信息来源 优先检查
HTTP 系统代理 代理请求通常已携带目标主机名 应用是否遵循系统代理，不能由此推断全机 DNS 已接管
TUN 透明接管 可通过 Fake-IP 映射还原域名 DNS 查询与虚拟地址连接是否进入同一内核
局域网网关 由网关 DNS 建立映射 终端的 DNS、网关路由和回程路径是否一致
应用自带加密 DNS 可能绕过内核 DNS，直接取得真实 IP 应用安全 DNS、系统加密 DNS及已有 VPN 的设置

TUN 提供虚拟网络接口和接管路径，Fake-IP 提供 DNS 映射，两者属于不同层。打开 TUN 不代表每个应用的 DoH 请求都会被变成普通 DNS 查询；启用 DNS 的 enhanced-mode: fake-ip 也不会自动替系统配置全部路由。

  • 记录客户端版本、内核名称和内核版本，确认正在运行的并非另一个后台实例。
  • 保存当前生效配置，以及客户端单独维护的覆写片段。只备份订阅原文可能遗漏 DNS 设置。
  • 检查其他 VPN、网关软件和安全软件是否同时修改 DNS 或路由。
  • 初次验证只改变 DNS 模式与必要接管设置，不同时改节点、策略组和规则顺序。

四、Fake-IP 配置片段与字段边界

mixed-port: 7890
mode: rule
allow-lan: false

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"
    - "*.home.arpa"
  nameserver:
    - 1.1.1.1

两个端口不能混用

7890 是示例中的 HTTP/SOCKS 混合代理端口；1053 是内核 DNS 监听端口。浏览器的代理设置不能填写 DNS 端口。多数系统 DNS 设置界面也不能直接指定非标准端口，因此这个片段适合显式带端口的查询工具，不会仅靠加载 YAML 就自动接管系统 DNS。

listen: 127.0.0.1:1053 将监听限定在本机。局域网其他设备不能用它作为 DNS 服务器；要服务局域网，需要另行规划监听地址、防火墙和流量路由。allow-lan: false 用于代理入口的局域网访问控制，不能替代 DNS 监听地址的安全设置。

过滤模式必须与内核能力对应

在支持 fake-ip-filter-mode 的 mihomo 中，示例明确选择 blacklist：匹配列表的域名不返回 Fake-IP，而是走真实解析。若选择 whitelist，列表语义会反转为仅对匹配项使用 Fake-IP。旧内核未必支持模式字段，不能把未知字段被忽略当成配置成功。

示例 ipv6: false 用于收窄本次 DNS 验证范围，不等于关闭操作系统 IPv6，也不证明其他解析路径不会返回 AAAA 记录。生产环境需要结合 IPv6 路由和实际内核能力重新评估。更多字段可对照配置大全逐项核对。

五、局域网兼容问题与排除项的选择

部分应用需要真实地址，而不只是一个能够建立连接的标记。例如 NAS 管理工具可能检查服务器是否位于本地网段，打印工具可能把解析结果交给不经过代理的发现组件，某些程序还会把 IP 地址发送给其他设备使用。这些场景中，给单个域名保留真实解析通常比排除全部域名更容易控制影响。

排除 Fake-IP 不等于指定局域网 DNS

把 "*.home.arpa" 加入过滤列表后，内核只是改为查询真实地址。公网 DNS 通常不知道家庭网络中的主机记录。若 NAS 名称由路由器提供，仍需要把对应域名交给路由器 DNS，例如通过内核支持的 nameserver-policy 配置定向解析，并确认路由器的 DNS 服务可达。

.local 常用于 mDNS，本质上与向单播 DNS 服务器发送普通查询不同。把 "*.local" 加入列表不会自动恢复组播发现，也不会让内核变成 mDNS 转发器。投屏或打印发现失败时，还要检查局域网访问权限、组播流量和 TUN 路由范围。

  • 先限定域名：单个设备有问题时，优先针对该设备名称验证，避免直接加入范围过大的通配项。
  • 再确认解析来源：排除后应拿到可信本地 DNS 返回的实际地址，而不是公网 DNS 的不存在应答。
  • 最后检查连接规则：返回了真实地址，不表示流量自动直连；规则仍可能把该域名送入代理组。

不同客户端对列表覆写可能采用替换或合并策略，内核也可能有版本相关的默认排除项。修改后应查看最终生效配置，而不是只看编辑器中新增的几行。不要为了消除一个兼容问题把所有域名都排除，否则很难再验证 Fake-IP 是否参与了处理。

六、按查询、映射、规则和出站顺序验证

1. 单独验证内核 DNS 应答

在已安装 dig 的 macOS、Linux 或其他环境中，针对上述本机监听地址执行：

dig @127.0.0.1 -p 1053 example.com A +short

若域名未被排除，预期返回所配置范围内的虚拟 IPv4 地址；具体地址不固定。若超时，先查内核是否启动、DNS 是否启用及 1053 是否被占用。若返回真实地址，则核对过滤模式、默认排除项，以及当前运行的配置是否确实包含修改。这里是预期行为说明，不是本站实测记录。

2. 使用实际应用验证连接接管

确认系统或应用的 DNS 已按预定路径接入后，用浏览器打开测试域名，同时观察客户端的连接记录。应核对目标域名、命中规则、出站策略和连接错误，而不只是观察“网页是否打开”。直接向内核运行一次 dig，并不会自动让浏览器采用同一解析路径。

显式 HTTP 代理请求本身通常携带域名，因此“通过代理端口访问成功”只能验证那条代理路径，不能单独证明 TUN 的 Fake-IP 回查正常。同样，向虚拟地址执行 ping 的结果不适合判断 HTTPS 是否可用，ICMP 的处理与 TCP 连接并不相同。

3. 对照错误出现的位置

现象 优先检查 下一步
查询得到虚拟地址，连接记录为空 应用连接是否绕过内核 检查 TUN 路由、应用排除设置及其他 VPN
重启内核后部分网站失败 应用缓存是否仍持有旧虚拟地址 关闭旧连接，刷新 DNS 缓存并重新查询
排除 NAS 域名后仍无法解析 该域名是否交给了知道本地记录的 DNS 检查定向解析及路由器 DNS 应答
域名与规则都正确，但出站超时 节点、直连目标或出站解析是否可用 转向链路排障，不继续扩大过滤列表

4. 清理缓存后再做单变量复测

在 Windows 中可使用 ipconfig /flushdns 清理系统 DNS 缓存；Linux 若使用 systemd-resolved，可运行 resolvectl flush-caches。浏览器、应用及内核可能另有缓存，系统命令不会清空所有层。关闭测试应用的旧连接后重新发起请求，才能减少旧结果的干扰。

支持的内核可用 profile.store-fake-ip 持久化映射，但这不是路由配置的替代品，也不能保证外部缓存与映射始终同步。更换地址池或清除内核缓存后，仍应让应用重新解析。

七、常见问题与回退方式

Fake-IP 能保证所有域名规则都命中吗？

不能。应用直接访问 IP、自带 DNS 绕过内核、映射丢失，或规则被更靠前的条目截获，都可能影响匹配。流量嗅探有时能从协议中补充主机名信息，但它是独立能力，不能保证对加密或非标准协议都有效。

启用 Fake-IP 后，所有域名都在代理服务器解析吗？

不是。应用看到虚拟地址，只说明本地 DNS 应答采用了映射机制。真实解析发生在本地还是远端，仍取决于规则、出站协议和节点配置。代理服务器自身的域名也需要可用的解析路径，应避免依赖尚未建立的代理连接形成循环。

修改过滤列表后要不要更新订阅？

通常需要应用配置或重载内核，并让应用重新查询，不必把更新订阅作为固定步骤。若直接修改订阅生成的文件，下次更新可能覆盖改动。应在客户端支持的持久覆写入口保存修改，随后查看最终配置确认列表语义。

如果出现大范围连接失败，先恢复之前保存的 DNS 与接管配置，再处理系统和应用缓存。只把模式改回 redir-host 而保留旧虚拟地址缓存，可能让故障暂时持续；只退出客户端却留下系统代理或 DNS 指向已停止的本地端口，也会造成新的断网表象。

提交排障信息时，保留客户端与内核版本、查询命令及结果、命中规则和错误时间，并移除订阅 URL、令牌与节点凭据。验证目标应是“查询和连接进入同一内核、域名映射有效、规则与出站符合预期”，而不是单纯追求 DNS 结果显示为某个地址段。

Clash下载