DNS 泄漏检测方法与防泄漏配置:远程 DNS、FakeDNS 与路由规则实操

1. DNS 泄漏判断：先确定哪些查询应该走代理

访问一个域名通常涉及两条路径：先获取 IP 地址，再建立业务连接。网页连接经过代理，不代表前面的 DNS 查询也经过代理。系统代理主要改变支持代理的应用如何联网，通常不会接管整台设备的 UDP 53 查询。

本文把“本应由代理承载的域名查询，却从本地网络发出”作为排查对象。若路由策略明确要求局域网域名、本地域名或指定站点直连，这些查询走本地解析器属于策略结果；若目标是所有公网查询随代理转发，就必须进一步限制本地回退与应用绕行。

2. 建立对照：浏览器检测与本机抓包一起看

先暂停代理，记录一次 DNS 检测页显示的解析器信息；再启用代理，用同一个浏览器重新测试。检测页通常通过随机子域名触发查询，能减少旧缓存的影响，但主要覆盖当前浏览器的解析路径，不能证明其他应用也受到接管。

1. 记录基线

   记下当前网络、代理模式、浏览器安全 DNS 状态和系统私有 DNS 状态。先完成直连测试，再启用代理；两次测试保持其他设置不变。

2. 清理缓存

   Windows 可运行下方命令清理系统 DNS 缓存。浏览器可能另有缓存，应关闭相关页面后重新打开。已建立的连接不会因为清缓存自动改走新路径。

3. 复测随机域

   在 DNS 检测页重新发起测试，不要只刷新上一轮结果。记录解析器地址和服务商，再与直连结果对照，不以页面显示的单一地区作结论。

4. 核对出口

   在实际联网网卡上观察 UDP/TCP 53 流量。检查是否有测试域名直接发往路由器或运营商解析器，并结合内核日志确认远程 DNS 的出站。

ipconfig /flushdns
nslookup example.com

nslookup example.com 用于观察系统侧的查询行为，不是 HTTP 或 SOCKS 代理测试。仅开启系统代理时，它仍可能向系统指定的 DNS 发包。开启 TUN 后是否被接管，则取决于该模式的 DNS 劫持与路由设置。

3. v2rayN：系统代理、TUN 与远程 DNS 分开配置

v2rayN 是桌面客户端，实际解析和路由由所选内核及生成配置共同决定。先在主界面确认当前节点可用，再检查「设置」→「DNS 设置」。不同构建的字段布局会变化，若当前界面没有对应选项，应查看实际生成的配置，不要把其他版本的截图当成固定菜单。

1. 确认接管范围

   只测试浏览器时，可以先使用系统代理。需要覆盖不遵守系统代理的应用时，再启用主界面的 TUN 模式，并确认系统授权成功。TUN 开关开启不等于 DNS 劫持已经生效。

2. 填写远程源

   进入「设置」→「DNS 设置」，在当前内核对应的远程 DNS 字段配置受支持的解析地址。例如 https://1.1.1.1/dns-query 是 DoH 地址，不能填入只接受普通 IP 的输入框。

3. 检查解析路由

   查看「设置」→「路由设置」及当前启用的规则集。确认远程 DNS 的连接没有被前面的直连规则截走；同时保留节点服务器地址所需的引导解析路径。

4. 重启并复测

   保存后重启当前服务，清理缓存，再做同一组对照测试。切换 TUN 后另测系统侧查询，避免只凭浏览器成功就认定整机 DNS 已受接管。

系统代理模式还要留意本地监听地址。应用使用的 HTTP 或 SOCKS 端口必须与客户端显示值一致；DNS 的 53 端口不是 SOCKS 入口。不要把远程 DNS 地址填进应用的代理服务器栏，也不要为解决 DNS 问题随意开放局域网监听。

4. v2rayNG：核对本地 DNS、远程 DNS 与应用范围

v2rayNG 使用 Android 的 VPN 接口承接应用流量，内核侧采用 Xray。这里的“本地 DNS”通常指解析策略中的本地侧服务器，不必然表示只监听在本机回环地址。应结合设置项说明和生成配置理解，不能仅凭名称判断数据是否出设备。

1. 核对应用范围

   进入「设置」→「分应用代理」，检查当前是仅代理选中应用，还是绕过选中应用。用于检测的浏览器必须处于代理范围内，否则测到的是该应用的直连行为。

2. 启用内核解析

   进入「设置」，找到「启用本地 DNS」及 DNS 配置项。若当前构建提供该开关，启用后检查「远程 DNS」与「本地 DNS」的具体值；菜单文字可能随版本略有不同。

3. 设置远程源

   在「远程 DNS」中填写当前内核支持的服务器地址，例如 https://1.1.1.1/dns-query。先测试单个远程源，不同时叠加多个未验证的回退服务器。

4. 检查系统解析

   在 Android 系统设置中搜索「私人 DNS」或「私有 DNS」。记录原状态后暂时关闭用于对照；测试完成再恢复，并确认恢复后的加密解析连接是否仍符合预期路由。

5. 重连并看日志

   断开后重新启动连接，检查域名解析错误与请求超时。若只有被排除的应用仍使用本地解析器，应先修正应用范围，而不是继续更换 DNS 地址。

5. 远程 DNS 路由：加密地址不等于代理出站

DoH 解决的是查询内容在传输中的加密问题；是否使用代理，由连接的路由决定。Xray 内置 DNS 的普通 https:// 查询可以进入核心路由处理，而 https+local:// 属于本地查询模式，不应在要求经核心代理路由的场景中混用。

下面是用于说明关系的 Xray 配置片段，不是完整客户端配置。它给内置 DNS 查询标记 dns-query，再把该标记的流量交给已有的 proxy 出站。使用前必须确认当前内核支持对应字段，且实际代理出站标签确实叫 proxy。

{
  "dns": {
    "tag": "dns-query",
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIPv4"
  },
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-query"],
        "outboundTag": "proxy"
      }
    ]
  }
}

• 合并而非覆盖：把 DNS 规则放进现有规则列表的适当位置，通常应早于会匹配它的宽泛直连规则。不要直接替换客户端生成的整个 routing。
• 区分内部与外部：dns.tag 标记的是内置 DNS 发出的查询，不会自动把所有应用发往 UDP 53 的数据包接入内置解析器。系统侧仍需要 DNS 劫持或专用 DNS 入站处理。
• 保留引导解析：若节点地址是域名，而远程 DNS 又必须通过该节点才能访问，会形成启动依赖。应为节点域名提供可达的引导解析，或在确认地址有效时使用相应的固定映射。
• 明确 IPv6 策略：示例中的 UseIPv4 仅用于限定本次解析变量，不等于关闭系统 IPv6，也不是通用防泄漏开关。需要 IPv6 时，应同时验证 AAAA 解析和 IPv6 连接的路由。

6. FakeDNS：返回虚拟地址，还需要后续接管

FakeDNS 不直接向应用返回目标站点的真实 IP，而是分配一个虚拟地址，并保存域名与虚拟地址的映射。应用连接该地址时，内核利用映射恢复域名，再交给路由和出站处理。它减少了某些场景下的提前真实解析，但不是远程加密 DNS 的替代品。

常见的 IPv4 虚拟地址池是 198.18.0.0/15，即 198.18.0.0 至 198.19.255.255。这段地址不是目标网站的公网地址。若查询被 FakeDNS 处理，后续连接却绕过接管，应用就会尝试访问一个无法正常到达目标的虚拟地址。

在 v2rayNG 中，若「设置」提供「启用虚拟 DNS」，应先按该构建的要求开启本地 DNS，再启用虚拟 DNS，并核对「嗅探」相关设置是否支持 FakeDNS 恢复。在 v2rayN 中则应核对 TUN 与当前内核的 FakeDNS 配合方式。不要仅添加一个虚拟地址池，就认为 DNS 接管和域名恢复已经完成。

7. 日志排错：区分解析失败与连接失败

先记录错误出现的时间和目标地址，再关联同一时段的日志。下列字符串可能出现在日志链中，前缀与完整信息随内核版本变化。单独一条超时不能证明泄漏，也不能证明 DNS 服务器本身不可用。

8. 常见问题与最终复测

最后把代理重连、客户端重启和网络切换都纳入复测。Wi-Fi 与移动网络可能下发不同的解析器和 IPv6 路由；只在一个网络完成的检测，不能代表另一种网络的结果。保留配置变更记录，发生异常时逐项回退。

• 浏览器检测结果符合预期，且已核对浏览器自己的安全 DNS 设置。
• 应受接管的系统查询没有从物理网卡直接发送到非预期解析器。
• 远程 DNS 的连接匹配代理出站，节点地址仍能完成启动所需的解析。
• 局域网域名、直连站点和代理站点分别完成验证。
• 启用 FakeDNS 时，内核重启后清理旧缓存并重新测试虚拟地址连接。