前言

随着折腾次数越多，对于DNS的理解也逐渐加深，在新手时期觉得“聪明人不做选择题”，“我全都要”的想法渐渐改变。

特别是在于DNS解析这块，并不是前置解析越快越好，尤其是在OpenClash的FakeIP模式下。

原理概述

其中主要的原因也就是因为网络技术的发展，大多数科学上网都是FakeIP模式，基于这个基础，给还在使用FakeIP模式的同学一点建议。

工作原理与核心区别

Redir-Host（真实 IP 模式）

在传统代理模式下，客户端发起网络请求的完整流程如下：

  1. 本地解析： 客户端请求解析 example.com，代理内核拦截并向远端/上游 DNS 发起查询。

  2. 返回真实 IP： 代理内核获取到该域名的真实 IP（例如 93.184.216.34）并返回给客户端。

  3. 发起连接： 客户端向 93.184.216.34 发起 TCP/UDP 握手，流量被代理内核拦截。

  4. 反向推断与分流： 代理内核需要检查这个 IP 对应哪个域名，判断是否走代理节点（如果匹配不到规则，可能需要节点端再次解析）。

Fake-IP（伪造/虚假 IP 模式）

Fake-IP 打破了先查 DNS 再连网络的逻辑：

  1. 即时分配假 IP： 客户端请求解析 example.com 时，代理内核完全不向上游查询，而是立刻从保留私网地址池（如 198.18.0.0/16）中随机分配一个未被占用的伪造 IP（例如 198.18.0.2）返回给客户端。

  2. 记录映射关系： 内核在本地内存中存下一张临时映射表：198.18.0.2 <-> example.com。

  3. 发起连接： 客户端毫不犹豫地向 198.18.0.2 发起 TCP/UDP 连接，流量到达代理内核。

  4. 域名级代理转发： 内核查表还原出原始域名 example.com，命中规则后直接把域名打包发给远端代理服务器，由远端服务器在境外机房完成 DNS 解析并建连。

为什么 Fake-IP 明显比 Redir-Host 更快？

  1. DNS 响应几乎瞬间完成

    fake-ip 模式下，核心收到查询后不立刻去上游查真实 IP，而是直接从本地假 IP 池分配一个并返回。客户端马上就能发起 TCP/UDP 连接。
    redir-host 必须等上游 DNS（nameserver / fallback）返回真实结果，这个过程有网络往返延迟（实测常见 45–120 ms）。

  2. 可能节省一次本地解析

    如果最终判定需要走代理，真实解析可以放到远端节点完成，本地就少了一次 DNS 查询。对需要代理的站点，首包时间更短。

  3. 规则匹配更直接、减少等待

    域名信息一直保留在核心内部映射表里，DOMAIN 类规则命中更快、更准，减少因为 IP 变化或污染导致的重试。

实测情况就是：Fake-IP 首次 DNS 解析延迟接近 0，而 Redir-Host 有明显等待；吞吐量和内存差异很小。

对比及区别

对比项 Fake-IP Redir-Host
返回给客户端的 IP 假 IP（通常是 198.18.0.0/15 或 /16 私有段） 真实 IP（上游 DNS 解析结果）
真实解析时机 客户端发起连接后，由核心根据规则再解析（可在出口节点解析） 客户端发起 DNS 查询时就立刻真实解析
规则匹配依据 直接用域名匹配（DOMAIN / DOMAIN-SUFFIX 等），最精确 先拿到真实 IP，再靠反向映射或嗅探（SNI/Host）恢复域名，精度略低
DNS 泄漏风险 极低（本地几乎不发起真实域名查询） 较高（本地会真实查询，需额外规则/加密 DNS 防护）
兼容性 少数应用/设备对假 IP 不兼容（需 fake-ip-filter 排除） 更好，接近传统 DNS 行为
CDN / GEOIP 依赖出口解析，国内 CDN 可能略差 拿到真实 IP 后 GEOIP 更准确
首次请求延迟 接近 0（本地直接返回假 IP） 需要等上游 DNS 返回（通常几十到上百 ms）

当然也不是Fake-IP就一定好，只是大多数情况下，首选都是Fake-IP，可能遇到的问题是部分银行App 无法登录（至少目前我没有遇到过这类问题），就需要单独再配置 fake-ip-filter 来解决，而使用Redir-Host相对兼容性更强。

FakeIP模式DNS的建议

了解了上面的基础之后，我们就可以得到一个结论：

两者目标冲突，在纯 fake-ip 模式下，直接把 SmartDNS / MosDNS 当上游通常是多余的，甚至有害。它们的设计目标是“在本地选出最优的真实 IP”。但在 Fake-IP 模式下，本地根本不产生真实 IP（对于代理流量），优化目标自然就不存在了。 它们更适合作为 Redir-Host 模式的上游，或者用来处理必须直连的域名（作为 fake-ip-filter 的解析器）。

很多人喜欢把MosDNS放在 Clash 前面做前置分流： MosDNS 先根据域名列表决定“国内域名返回真实 IP、国外域名返回假 IP”，再把假 IP 流量交给 Clash。这种“fakeip 分流大法”能让国内流量完全绕过代理核心，体验更好，但配置复杂，得到的收益也不明显，我个人而言不建议。

FakeIP模式DNS的应用

OpenClash独立使用

OpenClash的 nameserver 填写国内公共DNS即可，fallback + nameserver-policy不填，并且开启DNS劫持即可。

这是最基础的应用，只要科学上网即可。

OpenClash搭配AdguarHome广告过滤

  1. 安装AdguardHome；

  2. 将OpenWrt的DNS监听端口改为其他，比如5353；

  3. 打开AdguardHome配置界面

    • 设置DNS监听端口为 53

    • 上游DNS设置为OpenClash的 127.0.0.1:7874

    • 关闭DNS缓存（FakeIP模式下不需要缓存，因为都是假IP）

    • 备用DNS不要填，留空

    • Bootstrap DNS填写运营商DNS或者国内公共DNS

  4. 关闭OpenClash的DNS劫持

  5. OpenClash的 nameserver 填写国内公共DNS，fallback + nameserver-policy不填

这套架构之所以能完美运转，是因为它把网络逻辑切分成了两个明确的阶段：

  • 阶段 1（DNS 查询层）： 由 AdGuard Home 先行拦截做规则过滤，放行后的请求交给 OpenClash 赋予 Fake-IP；

  • 阶段 2（流量转发层）： 客户端拿到 Fake-IP 发起真正的网络连接时，由 OpenClash 依照分流规则把流量推向代理或直连。

因此，达到科学上网的同时又能兼顾广告过滤的效果。

这套架构在我的ESXI虚拟设备上完美运行。

但是在我办公室那台用红米AX6000刷的OpenWrt设备上，需要重启一下才行。

结论

网络架构的搭建从来不是“插件套得越多就越快”，清晰的边界与合理的职责划分才是稳定和低延迟的基石。

回顾整片文章，其高效的核心逻辑在于“各司其职，把 DNS 做减法”：

  1. AdGuard Home 专注于判定与拦截： 站在流量的最前端，通过纯粹的黑名单规则阻断广告域名，将不需要的无效请求直接掐死在摇篮里；

  2. Fake-IP 消除了首屏等待： 代理内核不再进行繁冗的本地双重解析，以小于 1ms 的极速响应生成假 IP，将真正的海外 DNS 解析彻底转交至远端节点，天然杜绝了本地污染；

  3. 砍掉冗余的 DNS 中间件： 不再引入 SmartDNS 或 MosDNS 搞多层并发测速，既规避了国内 CDN 乱跳、跨运营商调度的负优化，也彻底消除了潜在的 DNS 环路风险。

当 AdGuard Home 做好门卫、OpenClash 接管路由，整套拓扑便能在兼顾去广告与科学上网的同时，榨干宽带的每一毫秒延迟。很多时候，软路由网络配置最好的优化，恰恰就是学会做减法。