FakeDNS 原理详解:适用场景与开启前的注意事项

FakeDNS 原理：用虚拟地址保留域名

FakeDNS 不是代理协议，也不是加密 DNS。普通 DNS 为域名返回实际服务地址；FakeDNS 则从专用地址池分配一个虚拟 IP，并记录“域名与虚拟 IP”的对应关系。应用随后连接这个地址时，接管流量的内核通过映射找回原始域名，再执行路由与出站处理。

Xray 在这条链路中需要同时处理 DNS 请求和后续连接。例如，应用查询 example.com，得到地址池中的 198.18.0.1；随后发往该地址的连接必须重新进入持有映射的内核。这个地址只是示意分配结果，不是该域名的真实地址，也不是应当填进节点配置的服务器地址。

TUN 与域名分流：FakeDNS 解决哪一层问题

v2rayN 的系统代理通常由应用主动使用 HTTP 或 SOCKS 代理，应用有机会把域名直接交给代理端。TUN 接管的则是网络层数据包，内核看到的目标可能已经是解析后的 IP。FakeDNS 的价值，是在这种情况下保留可用于域名规则匹配的信息。

v2rayNG 通过安卓 VPN 接口接收设备流量，但 VPN 接管不等于自动启用 FakeDNS。DNS 是否进入内核、内核是否分配虚拟地址、连接是否还原域名，是三个独立条件。TLS 或 HTTP 嗅探也能提供部分域名信息，不过它受协议和应用行为限制，不能视为所有连接都可靠可用的替代方案。

VLESS 与 VMess 负责代理连接，FakeDNS 负责本地 DNS 与目标信息处理；切换代理协议并不会自动修好映射链路。v2flyNG 使用 V2Fly 内核，配置能力与字段支持应按实际内核核对，不能把 Xray 示例直接当作三款客户端通用配置。

地址池与配置字段：先理解三个数字

Xray 的 FakeDNS 配置可使用 198.18.0.0/15 作为 IPv4 地址池。该网段属于用于基准测试的特殊用途地址空间，不是可直接访问公网服务的普通地址。网段包含的地址总数与 poolSize 不是同一个概念：前者由前缀长度决定，后者控制实现中的映射池容量。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

Xray 的这段示例只展示顶层地址池定义，不是可独立运行的完整配置。实际接入还涉及内置 DNS 的 fakedns 服务器项，以及接收连接的入站中相应的域名恢复设置，例如 sniffing.destOverride 对 fakedns 的支持。仅粘贴地址池，并不会让系统 DNS 自动改道。

• 先核对生成配置：v2rayN 的 TUN 实现与普通代理入站可能采用不同处理链路，应检查当前运行组件实际接受的配置，而不是把 Xray 字段粘贴到所有配置文件。
• 检查地址冲突：企业 VPN、实验网络或静态路由如果已经使用 198.18.0.0/15，需要重新规划地址池与路由，避免同一网段被两套用途争用。
• 单独检查 IPv6：只有 IPv4 地址池并不代表 AAAA 查询也已经正确处理。应确认当前实现的 IPv6 策略，避免双栈应用走出另一条未验证的路径。

适用场景：哪些流量值得启用

FakeDNS 更适合依赖域名规则、又难以从应用直接获得域名的透明接管场景。它可以减少前置真实解析对域名识别的影响，但不保证网页必然更快。最终出站、服务器可达性和真实目标解析仍然会影响连接结果。

FakeDNS 对内网域名尤其需要谨慎。公司服务可能必须通过指定 DNS 才能得到私有地址；让这些查询使用真实解析，再为相应连接设置直连，往往更容易维持原有访问逻辑。具体例外要配置在当前 DNS 与路由实现中，不能只加一条直连规则就假定解析路径也随之改变。

开启前检查：DNS、出站与缓存要一起看

1. 保存基线。记录当前客户端版本、运行内核版本、DNS 设置、TUN 或 VPN 状态。使用同一个域名完成一次访问并保存日志，后续才能比较变化。
2. 确认解析入口。检查系统 DNS 是否被接管；浏览器的安全 DNS、应用内 DoH 可能绕过该入口。测试时可临时让测试应用使用系统 DNS，测试结束后再恢复原设置。
3. 确认连接回流。检查虚拟地址池是否由当前 TUN 或 VPN 路由接收。安卓按应用代理若排除了测试应用，该应用可能拿到虚拟地址，却无法把连接送回内核。
4. 确认真实解析出口。代理服务器地址如果是域名，必须有可用的引导解析路径，不能依赖尚未建立的代理完成解析。直连目标也仍可能需要真实 IP。
5. 只改一个变量。先保持节点与路由预设不变，仅调整 FakeDNS 相关设置。不要同时切换内核、协议、DNS 和分流规则，否则难以定位失败环节。

v2rayN 与 v2rayNG 的界面项目会随版本变化，判断依据应落在运行配置和日志，而不是某张旧截图中的开关位置。若当前版本没有暴露所需配置，优先保持已验证的模式；自定义配置需要同时理解 DNS、入站与路由，不能只添加一个字段。

验证与回退：把解析成功和连接成功分开

FakeDNS 测试应当分为两步：先观察系统查询结果，再观察同一域名的实际连接。Windows 可以在命令提示符中执行下面的命令。nslookup 验证的是其当前使用的 DNS 查询路径，不代表浏览器自带 DNS 也走同一条路径。

ipconfig /flushdns
nslookup example.com

• 解析阶段：如果该查询应由 FakeDNS 处理，检查返回地址是否位于配置的虚拟地址池内。返回真实地址时，先确认是不是命中了真实解析例外，而不是立即判定失败。
• 连接阶段：在测试应用中访问同一域名，观察日志中的目标域名、路由规则与出站标签。虚拟地址不应作为最终公网服务地址直接发送到普通网络。
• 对照阶段：额外测试一个内网域名和一个直接使用 IP 的连接，确认例外没有受到影响。测试条件保持相同，不把节点波动误判为 FakeDNS 故障。
• 回退阶段：先恢复原 DNS 与接管设置，重启客户端连接，再刷新系统缓存并完全退出、重新打开测试应用。安卓应用若仍持有旧结果，可先强制停止该应用后再启动。

FakeDNS 的映射通常属于运行时状态。内核重启、映射淘汰或配置变化后，应用可能还缓存着旧虚拟地址，而新的内核已经不知道它对应哪个域名。此时不断更换节点通常无效，应先清理缓存并重建连接。Windows 的 ipconfig /flushdns 只刷新系统 DNS 缓存，不会替代所有应用自身的缓存清理。

常见问题：虚拟地址、应用冲突与耗电

FakeDNS 的开启标准应是可验证的域名恢复与正确分流。v2rayN、v2rayNG 或 v2flyNG 已经稳定工作的配置，不需要仅为增加功能而调整。需要引入时，先确保查询入口、虚拟地址路由、真实解析例外和缓存回退都能解释清楚，再扩展到日常使用。