FakeDNS 原理详解:虚拟 IP 如何加速域名分流与哪些场景不该开

FakeDNS 不是公共 DNS，而是一张临时映射表

省掉一次真实解析，具体省在代理出站之前

• 域名规则可以在连接建立前命中，不必依赖反向查询猜测目标名称。
• 同一映射仍在有效期内时，重复连接可直接关联原始域名。
• 代理域名不必先暴露给本地默认解析器，再决定是否走代理。
• 纯 IP 连接没有原始域名，FakeDNS 无法为它补造可靠的域名信息。

TUN、DNS 劫持与流量嗅探必须形成闭环

1. 在客户端主界面选中一个可用的 VMess、VLESS 或其他已导入节点，先完成普通代理连通测试。
2. 打开「设置」→「参数设置」，确认本地混合监听端口没有与其他程序冲突；本文示例使用 10808。
3. 进入「设置」→「Tun 模式设置」，核对虚拟网卡、DNS 接管和自动路由选项，再返回主界面开启 Tun。
4. 执行一次 nslookup example.com 127.0.0.1 或使用系统查询工具，观察响应是否落在配置的虚拟地址池。
5. 访问该域名并查看核心日志，确认路由记录显示的是域名规则，而不是仅显示 198.18.x.x。

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "223.5.5.5"
    ]
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

为什么部分应用会在 FakeDNS 下异常

• 应用把查询结果保存到磁盘，切换网络后继续使用过期虚拟 IP。
• 下载器把解析与传输拆分到不同进程，后者不在 TUN 接管范围内。
• 游戏或实时通信程序直接使用服务器 IP，域名映射没有参与机会。
• 企业安全软件检查返回地址范围，把 198.18.0.0/15 判定为不可访问地址。
• 虚拟机、容器或第二条隧道配置了优先级更高的同网段路由。

这些场景不建议开启 FakeDNS

1. 系统代理已经覆盖浏览器和办公软件，域名规则能在日志中直接命中。
2. 网络中存在大量短主机名、内部搜索域或只能由路由器解析的名称。
3. 关键应用使用自带加密 DNS，且无法关闭或纳入 TUN 接管。
4. 正在使用虚拟机、容器或其他隧道，占用了 198.18.0.0/15 或相邻路由。
5. 当前问题是节点握手失败、订阅过期或端口占用，这些故障与 FakeDNS 无关。

用日志和对照测试判断是否真的生效

1. 关闭目标应用，清理系统 DNS 缓存，记录客户端当前核心与配置名称。
2. 开启 TUN 和 FakeDNS，查询一个此前未访问的测试域名，确认结果属于虚拟地址池。
3. 立即访问该域名，在日志中寻找完整域名、命中的路由规则和最终出站标签。
4. 分别测试一个代理域名、一个直连域名和一个局域网名称，避免只验证单一路径。
5. 关闭 FakeDNS 后重复相同测试，对比首个 DNS 响应时间、路由命中和应用兼容性。

检查顺序
1. DNS 返回地址是否属于 FakeDNS 地址池
2. TUN 路由是否捕获该虚拟地址
3. 核心日志是否恢复出原始域名
4. 域名是否命中预期路由规则
5. 代理或直连出站是否完成真实连接