DNS 泄漏检测方法与 v2rayN、v2rayNG 防泄漏配置实操

一、DNS 泄漏看的是查询路径，不只是国家标签

DNS 把域名转换成 IP。应用可能先让系统解析，再把 IP 交给代理；也可能把域名直接交给本地代理，由内核或远端处理。两条路径都能打开网页，但前者的查询可能先到本地网络提供的解析器。所谓泄漏，应当相对于你的规则判断：原本要求经过代理的域名，却经由本地出口解析，才是这里要处理的问题。

境内域名按计划使用本地 DNS，不应直接算作泄漏。VLESS、VMess 是代理协议，REALITY 是连接安全相关机制；它们不会自动决定操作系统怎样发出 DNS 请求。订阅里有节点参数，也不等于订阅同时带来了完整的 DNS 接管和路由策略。

二、在线 DNS 检测：做三组对照再下结论

在线检测通常让浏览器请求一批随机子域名，再观察哪些递归解析器来查询。结果显示的是解析器的出口，不一定是你设备连接的上游地址，也不一定与代理节点在同一城市。公共 DNS 使用任播和转发集群，单靠地图或国家名称无法判定泄漏。

1. 记录直连

   先停止代理，在浏览器访问 dnsleaktest.com，运行标准测试，再运行扩展测试。记录网络类型、时间、解析器 IP 和所属机构，作为本地网络的对照。

2. 测试代理

   启动客户端，确认同一个浏览器已被接管，重新开启测试。保留同一节点与同一网络，不要同时更改 DNS、路由、浏览器设置三个变量。

3. 隔离浏览器

   在浏览器设置内搜索「安全 DNS」，临时关闭该功能后再测一次。测试后是否恢复，取决于你是否打算单独管理浏览器的加密 DNS 路径。

4. 复测断线

   在允许短时中断网络的环境中断开代理节点，再发起新测试。如果目标是失败即停止访问，断线后仍能解析并访问新域名，就要检查系统直连、VPN 旁路与应用回退。

三、v2rayN 桌面端：系统代理与 TUN 分开排查

以下以 v2rayN 7.x 的设置结构为参考。不同小版本的分组名称可能调整，先核对当前运行的内核，再查看生成配置。尤其注意：TUN 模式实际使用的组件及 DNS 配置，可能与普通系统代理模式不同，修改 Xray 的 DNS 字段不一定会作用到当前 TUN 路径。

1. 确认运行模式

   打开「设置」→「参数设置」，核对核心相关选项；回到主界面检查「系统代理」与「启用 TUN」的实际状态。不要把托盘中的系统代理已开启，理解成所有程序都进入了隧道。

2. 检查解析上游

   进入「设置」→「DNS 设置」，分别检查当前内核对应的配置。远程上游可使用 https://1.1.1.1/dns-query 作为测试对象，随后确认该地址的连接路由到代理，而非仅填写一个 DoH URL。

3. 验证本地端口

   在「设置」→「参数设置」查看本地监听端口，再与浏览器或应用的代理地址核对。例如实际监听为 127.0.0.1:10808，应用也应使用该端口及对应代理类型；示例端口不能代替现场配置。

4. 清理旧缓存

   Windows 打开终端执行 ipconfig /flushdns，退出并重新打开浏览器，再测试新域名。已有连接和浏览器自己的缓存不会全部随这条命令消失。

Windows 多网卡环境还要检查 Wi-Fi、有线网卡与虚拟网卡。支持组策略的系统可在「计算机配置」→「管理模板」→「网络」→「DNS 客户端」中，将「关闭智能多宿主名称解析」设为「已启用」。这是减少并行查询的辅助措施，不替代 TUN 接管，也不是所有系统 DNS 回退的总开关。修改后仍以实际测试为准。

四、v2rayNG 安卓端：先收进 VPN，再检查私人 DNS

以下以 v2rayNG 1.9.x 常见设置结构为参考。v2rayNG 使用 Xray 内核，但系统 VPN 接管、安卓私人 DNS 和浏览器安全 DNS 属于不同层。v2flyNG 使用 V2Fly 内核，不能直接照搬这里的全部选项与配置字段。

1. 确认应用范围

   打开侧边栏「设置」→「分应用代理」，确认测试浏览器没有被排除。排查时可临时关闭分应用代理，让测试范围更清楚；如果使用允许列表，浏览器必须在列表内。

2. 核对本地 DNS

   进入侧边栏「设置」，找到「启用本地 DNS」并开启，核对「远程 DNS」与「国内 DNS」字段。部分版本将这些选项归入 DNS 设置分组；远程上游地址和国内上游地址应分开确认，不能凭字段名称推断最终出站。

3. 测试私人 DNS

   安卓原生设置路径通常为「设置」→「网络和互联网」→「私人 DNS」。先记录原值，再临时设为「关闭」建立内核 DNS 基线。厂商系统可能叫「私有 DNS」，可在系统设置搜索该名称。

4. 重建 VPN

   保存设置后停止连接，再重新启动，确认系统出现 VPN 连接状态。切换 Wi-Fi 与移动网络后各测一次；若只有一种网络异常，重点检查该网络的 IPv6、DNS 可达性与 VPN 重连情况。

5. 测试断线保护

   如需失败即停止访问，在安卓「设置」→「网络和互联网」→「VPN」→「v2rayNG」中检查「始终开启的 VPN」及「屏蔽未使用 VPN 的连接」。系统是否提供这些选项取决于设备与应用状态，启用后须验证分应用规则是否仍符合预期。

五、FakeDNS：减少提前解析，不代替远程上游

FakeDNS 返回合成地址，并在后续连接中把地址映射回域名。这样内核能保留域名信息，用于路由匹配和代理转发。它本身不是加密 DNS 服务，也不会自动让所有真实解析经过代理；需要真实 IP 的直连流量，仍要有合适的解析上游。

在 v2rayNG 的「设置」内查找「启用 Fake DNS」。启用前先确认「启用本地 DNS」已生效，保存后重启 VPN。桌面端则要依据当前 TUN 组件的 FakeIP/FakeDNS 支持方式配置，不能把 Xray 的 FakeDNS 对象直接复制到另一种配置格式里。

• 启用后网页异常，先重启应用并清理旧 DNS 缓存，再考虑回退设置。
• 如果应用拿到合成地址后绕过 VPN，该地址通常无法按预期使用，需要修正接管范围。
• 某些应用自行验证真实地址或使用独立解析，FakeDNS 可能不适合这类流量，应按应用测试。

六、关闭回退与路由兜底：分别处理两层配置

“关闭系统 DNS 回退”不是一个跨平台通用按钮。客户端内核的备用上游、Windows 的多网卡查询、安卓的网络切换，以及浏览器自己的安全 DNS，必须分别排查。Xray 的 disableFallback 只控制内置 DNS 的备用查询行为，不会替操作系统阻止直连。

下面是 Xray DNS 与路由的局部示例，不是完整配置。它只展示远程上游及其出口约束：现有配置必须已经定义标签为 proxy 的代理出站，并让应用查询进入内核 DNS。客户端自动生成的配置，应通过对应编辑入口调整并检查最终结果，不能覆盖原配置后直接运行。

{
  "dns": {
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIPv4",
    "disableFallback": true
  },
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "1.1.1.1/32"
        ],
        "port": "443",
        "network": "tcp",
        "outboundTag": "proxy"
      }
    ]
  }
}

此处使用 IP 形式的 DoH 地址，是为了减少解析上游域名时的引导依赖。UseIPv4 仅限制这段内置 DNS 查询的地址族，不会关闭系统 IPv6。示例没有域名分流，也没有应用 DNS 接管规则，不能据此宣称已经完成全局防泄漏。

• 远程上游先匹配：将远程 DNS 的连接规则放在可能命中的直连规则之前。Xray 路由按顺序匹配，前面命中后不会继续寻找后面的规则。
• 默认出站要检查：Xray 未命中规则时使用第一个出站。若目标是代理兜底，不能让第一个出站恰好是直连却不自知。
• 不要混用本地模式：选择上游时，留意 https+local:// 这类具有本地访问语义的地址形式；不能把它当作普通、受同样路由控制的远程 DoH 配置。
• 普通 DNS 要接管：UDP/TCP 53 可在合适的入站与路由设计中交给 DNS 出站处理。只屏蔽 53 端口会让部分应用解析失败，也无法覆盖 853 或 HTTPS 承载的查询。
• 节点域名要能启动：若代理服务器本身使用域名，代理建立前可能需要引导解析。应明确这条例外如何处理，避免 DNS 依赖代理、代理又依赖 DNS 的循环。

七、验收：同时看浏览器结果、日志和断线行为

完成修改后，不要只留一张检测页截图。应记录客户端版本、运行模式、网络类型、远程上游以及测试应用。先验证单一上游和全代理，再逐项恢复国内域名分流、浏览器安全 DNS、分应用规则；每恢复一项就复测，才能定位是哪一层改变了解析路径。

物理网卡没有 53 端口流量，只能说明没有观察到这类明文 DNS；浏览器 DoH 仍可能通过 443 直连。加密查询需要结合上游目标、连接路由和日志判断。临时调高日志级别后也应恢复日常级别，分享日志前先移除订阅地址、用户标识和访问域名。