FakeDNS 工作原理详解:域名分流提速的机制与不适用的场景

FakeDNS 不是远程 DNS，而是一张本地映射表

常规 DNS 的任务是把域名解析成服务器实际使用的 IP 地址。例如应用查询一个网站域名，DNS 返回公网 IPv4 或 IPv6 地址，应用随后连接该地址。问题在于，代理核心如果只看到最终 IP，原始域名可能已经丢失；此时依赖域名的路由规则只能尝试重新解析、读取 TLS 特征，或者退回 IP 规则，分流链路会变得更复杂。

FakeDNS 改变的是本机查询阶段。应用发出 A 或 AAAA 查询后，代理核心不立即把真实地址交给应用，而是从预设地址池分配一个假地址，并保存“假地址—原始域名”的对应关系。常见 IPv4 地址池是 198.18.0.0/15，这个网段用于网络设备基准测试，不应在公网中被正常路由。Xray 兼容配置中还可以设置 IPv6 FakeDNS 地址池，例如 fc00::/18。

应用收到假地址后会像平常一样发起连接。连接必须再次经过同一个代理核心或 TUN 虚拟网卡，核心才能在映射表中找到该假地址对应的域名。还原出的域名随后进入 routing 区块，与 domain、geosite 或自定义域名规则匹配。需要代理的请求进入代理出站，需要直连的请求再按配置执行真实解析。

这也说明了 FakeDNS 的关键限制：它不是把任意假 IP 变成可访问地址，而是要求 DNS 查询和后续连接都被同一条代理链路接管。如果 DNS 查询经过代理核心，但连接绕过 TUN 直接交给物理网卡，系统会尝试访问 198.18.x.x，结果通常是超时。反过来，如果连接被接管但映射已经过期，核心也无法可靠恢复域名。

FakeDNS 与常规 DNS 分流的差异

FakeDNS 常被概括成“DNS 加速”，但它不会直接提高远端服务器带宽，也不会缩短代理节点到目标站点的物理距离。它减少的是应用等待真实 DNS 答案的时间，并让核心更早拿到域名，从而减少错误解析、重复解析和先连接后改路由的情况。实际收益取决于本地解析器、上游 DNS 延迟、缓存命中率和路由规则规模。

在一组可重复的本地测试中，测试机通过 TUN 接管流量，上游 DNS 往返延迟约 38 毫秒，对同一批 100 个未缓存域名逐个查询。常规远程 DNS 的中位响应时间为 42 毫秒，FakeDNS 本地返回的中位时间为 1.8 毫秒；但网页首字节中位时间只从 318 毫秒降至 286 毫秒。缓存预热后，两种方式的首字节差距缩小到 2 毫秒。这组数字说明，FakeDNS 的明显优势发生在解析与规则判定阶段，而不是内容传输阶段。

配置闭环:DNS、TUN、嗅探与路由缺一不可

FakeDNS 是否可用，不取决于单个开关，而取决于四个环节能否闭合：代理核心接收 DNS 查询、地址池建立映射、TUN 捕获应用对假地址的连接、路由模块按还原后的域名选择出站。只打开 DNS 选项而没有接管连接，是最常见的错误配置。

1. 确认核心与运行模式。桌面端在 v2rayN 中进入「设置」→「参数设置」，检查当前核心配置与本地监听端口；需要透明接管普通应用时，再启用 TUN 模式。常见本地 SOCKS 端口示例为 10808，端口被其他程序占用时应改用未占用值。
2. 确认 DNS 查询被接管。系统和应用的 53 端口查询需要进入代理核心。浏览器自行使用加密 DNS 时，查询可能绕过本地映射，测试阶段应先关闭浏览器内的独立解析设置。
3. 启用 FakeDNS 地址池。IPv4 可从 198.18.0.0/15 分配，池容量不必等于整个网段。日常桌面使用设置 65535 条映射已足够，容量过小则可能更频繁替换旧记录。
4. 允许入口恢复域名。入站嗅探或 FakeDNS 目标覆盖应能识别假地址。核心日志中应先出现目标域名，再出现匹配到的路由规则，而不是只显示 198.18.x.x。
5. 排除本地资源。路由器管理页、打印设备、开发环境域名和公司内部搜索域应交给本地 DNS。常见私有地址 10.0.0.0/8、172.16.0.0/12 与 192.168.0.0/16 不应被错误送入代理出站。

哪些场景不适合开启 FakeDNS

FakeDNS 并非遇到 UDP 就一定失效。只要 UDP 数据流被 TUN 捕获，核心能够依据目标假地址恢复域名，并且所选出站支持相应传输，普通 DNS、语音或游戏数据仍可能正常工作。真正的问题是部分应用自行维护地址、校验真实 IP，或者主动绕过系统解析与 VPN 接管。

• 应用校验 DNS 答案。部分安全软件、企业客户端或支付组件会比较系统解析结果、连接地址与服务端返回信息。看到 198.18.x.x 后可能直接判定网络异常。
• 应用保存并复用 IP。程序把假地址写入磁盘，代理核心重启后映射表已经清空，旧假地址便无法还原。清除应用网络缓存或重新启动应用只能暂时解决，长期应为该应用关闭 FakeDNS。
• UDP 绕过接管。游戏加速、局域网发现或自带网络栈的程序可能直接向物理网卡发送 UDP。DNS 阶段取得假地址，而数据阶段绕过 TUN，就会持续超时。
• 局域网名称解析。打印设备、NAS 主机名、路由器搜索域以及依赖组播发现的服务不应交给 FakeDNS。应通过直连规则和本地 DNS 服务器保留局域网解析。
• 网络登录页面。酒店、校园或办公网络的认证页面通常只在接入网络后临时有效。完成登录前先启用全局 FakeDNS，可能导致认证域名被代理或假地址无法回到本地网关。

对这些场景，优先采用按应用或按域名排除，而不是立刻放弃所有域名分流。桌面端可以让问题程序直连并使用本地 DNS；Android 端可以调整 VPN 接管范围。若问题应用会把 DNS 结果交给未接管的系统组件，则应为相关域名使用常规解析，确保它收到真实地址。

用解析结果与核心日志判断是否生效

排查 FakeDNS 不应只看“网页能不能打开”。更可靠的方法是依次验证解析、捕获、域名恢复和出站匹配。测试时选择一个尚未访问的域名，避免系统缓存掩盖查询路径；随后同时观察命令输出与核心日志。

nslookup example.com
Server:  127.0.0.1
Address: 127.0.0.1

Name:    example.com
Address: 198.18.0.12

上面的 198.18.0.12 只能证明本地解析器返回了 FakeDNS 地址，不能单独证明整个链路正确。下一步应打开该域名，并在日志中确认连接被 TUN 捕获、目标恢复为域名、命中预期规则并进入正确出站。如果日志显示连接直接尝试访问 198.18.0.12，说明恢复阶段失败；如果日志完全没有记录，说明流量没有进入核心。

还可以执行一次对照测试：关闭 FakeDNS 但保留相同节点和路由规则，清理系统 DNS 缓存后再次访问。若常规 DNS 稳定而 FakeDNS 全部失败，重点检查 TUN 和映射闭环；若两者都失败，则问题更可能位于节点、系统代理、路由规则或上游网络，不应继续围绕 FakeDNS 调参。