V2Ray DNS 泄漏检测与防泄漏配置实操:检测方法、成因分析与修复步骤

代理连接显示正常，只能证明一部分应用流量进入了 V2Ray 或 Xray 内核。域名在连接建立前通常还要转换成 IP 地址；如果这一步仍由系统网络中的默认 DNS 完成，查询记录就可能沿本地网络独立发出。排查 DNS 泄漏的重点不是反复切换节点，而是确认“谁发起查询、查询经过哪个入口、最终由哪组解析器应答”。本文操作基线为 v2rayN 7.14.x、v2rayNG 1.10.x，较小版本的菜单文字可能略有调整，但检查顺序不变。

DNS 泄漏是什么：先拆开域名解析链路

访问一个域名时，应用可能自己解析，也可能把域名交给系统解析器，还可能把完整域名交给 HTTP 或 SOCKS 代理。三种路径的差别决定了 DNS 查询是否进入代理内核。使用系统代理时，只有遵循系统代理设置的应用流量会被接管；后台程序、部分命令行工具和自行发送 UDP 查询的应用，仍可能直接访问网络接口配置的 DNS。

DNS 泄漏不等同于“检测页出现多个解析器”。公共 DNS 服务常使用任播节点，一个查询可能显示多个出口位置；浏览器启用加密 DNS 后，也可能绕过操作系统设置，直接与浏览器指定的解析服务通信。真正需要关注的是：检测结果是否出现当前宽带或移动网络运营方的解析器、断开代理前后的解析器集合是否完全相同、查询是否以 UDP 或 TCP 53 明文流量离开本地接口。

V2Ray 与 Xray 配置中的 dns 对象负责内核内部解析，但它不会自动接管操作系统产生的所有 DNS 请求。只有域名已经进入内核，或者系统 DNS 流量被 TUN、透明入口等机制捕获时，内置 DNS 配置才有机会生效。这也是“已经写了 DNS 配置，检测结果仍没变化”最常见的原因。

建立检测基线：一次测试不能下结论

检测前先关闭浏览器中可能独立工作的安全 DNS，并暂时停用其他网络代理工具。保留当前网络连接，记录系统 DNS 地址、v2rayN 或 v2rayNG 的工作模式、所选节点以及路由模式。这样才能区分浏览器自己的解析结果与客户端接管后的结果。

1. 记录直连结果

   完全退出客户端后打开 DNS 检测页，分别执行标准测试与扩展测试。记录解析器数量、所属网络和国家或地区；扩展测试建议连续运行 2 次。

2. 启用系统代理

   在 v2rayN 7.14.x 中选择「系统代理」→「自动配置系统代理」，保持默认本地 SOCKS 端口 10808 与 HTTP 端口 10809，再用新的浏览器窗口重复测试。

3. 切换 TUN 模式

   进入「设置」→「参数设置」→「TUN 模式设置」，确认 DNS 劫持范围后启用 TUN。重新连接节点，等待 10 秒，再运行相同测试。

4. 比较三组数据

   对比直连、系统代理、TUN 三组结果。如果系统代理仍显示本地解析器而 TUN 不再显示，问题通常位于系统 DNS 捕获范围，而不是节点本身。

5. 执行断连复测

   关闭客户端后刷新检测页，确认系统网络恢复到基线结果。若退出后仍保留异常 DNS，检查网卡是否残留手动地址，并执行一次网络断开与重连。

一次扩展检测可能产生 20 至 50 个查询，公共解析服务会把它们分配给多个节点。更可靠的做法是连续测试 3 轮，每轮间隔约 15 秒，并把重复出现的解析器视为稳定结果。若只有某一轮出现一个不同地址，应先排除缓存、网络切换和解析服务负载均衡，不要立即修改整套配置。

还可以使用系统自带的网络观察工具核对 53 端口。测试时只打开一个检测页面，观察是否有目标端口为 53 的 UDP 或 TCP 连接从物理网卡发出。若 TUN 已启用但仍持续出现直连 53 流量，说明某个应用绕开了接管，或者 DNS 劫持规则未覆盖对应协议族。

测试状态	示例结果	优先判断
直连	3 个本地网络解析器，耗时 42–68 ms	基线数据，保留用于对照
系统代理	仍出现相同 3 个解析器	浏览器或系统 DNS 未进入内核
TUN 模式	仅出现配置的公共解析服务，耗时 85–120 ms	DNS 捕获与代理出站已生效
TUN 模式	公共解析器与本地解析器同时出现	存在旁路查询或协议族未覆盖

v2rayN 修复：内置 DNS 与路由规则要配套

v2rayN 桌面端通常使用 Xray 内核。修复时先确认核心类型与配置来源：普通订阅节点由客户端生成运行配置，自定义 JSON 则由用户直接维护。两者不要同时修改同一个字段，否则客户端更新订阅或重启核心后，手动内容可能被重新生成的配置覆盖。

1. 确认核心类型

   打开「设置」→「参数设置」→「Core 类型」，确认当前节点使用 Xray。保存后重启核心，并在日志顶部核对实际加载的核心名称与版本。

2. 检查本地端口

   在「设置」→「参数设置」→「基础设置」核对 SOCKS 端口 10808、HTTP 端口 10809 是否被其他程序占用。端口冲突会导致浏览器回落到直连。

3. 设置域名策略

   进入「设置」→「路由设置」，检查当前规则集的域名策略。需要基于解析结果匹配 IP 规则时可使用 IPIfNonMatch；只按域名规则分流时不要无条件提前解析全部域名。

4. 启用 DNS 捕获

   进入「设置」→「参数设置」→「TUN 模式设置」，启用 DNS 劫持并确认覆盖 UDP 53。保存后退出并重新启动客户端，使虚拟网卡和路由表完整重建。

5. 核对运行日志

   连接节点后打开日志，访问一个此前未解析过的域名。正常情况下应看到域名进入路由判断，不应连续出现本地解析超时或目标地址查找失败。

下面的结构用于说明内置 DNS 的关键字段，不应直接覆盖客户端生成的完整配置。queryStrategy 控制返回地址族，servers 决定候选解析器。若当前网络的 IPv6 路由不稳定，先使用 UseIPv4 建立可复现基线；确认链路正常后再按实际需求调整地址族策略。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "223.5.5.5"
    ]
  }
}

仅添加服务器地址还不够。内核发出的 DNS 请求也要经过明确的出站路径，否则加密 DNS 的连接仍可能按默认规则直连。对于按国内外域名分流的配置，应让特定解析服务的域名或地址匹配到预期出站，并把最终 DNS 规则放在会提前截获它的宽泛规则之前。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "network": "udp",
        "port": 53,
        "outboundTag": "proxy"
      }
    ]
  }
}

v2rayNG 与 v2flyNG：移动网络下检查 VPN 接管

v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核。两者的 DNS 字段支持范围与默认行为不完全相同，因此不要把桌面端自定义配置原样复制后直接启用。移动端排查首先要确认 VPN 连接是否真正建立，其次检查本地 DNS、远程 DNS、域名策略与按应用代理范围。

1. 记录网络类型

   分别在 Wi-Fi 与移动网络下测试，切换网络后停止连接并重新启动。不要沿用切换前的检测标签页，以免缓存结果混入新一轮数据。

2. 检查 VPN 设置

   在 v2rayNG 1.10.x 打开「设置」→「VPN 设置」，确认当前使用 VPN 模式，并检查分应用代理列表是否遗漏正在执行检测的浏览器。

3. 核对 DNS 项

   进入「设置」→「VPN 设置」→「DNS 设置」，检查本地 DNS 与远程 DNS。远程 DNS 应选择当前网络可达的地址，修改后停止并重新启动连接。

4. 检查域名策略

   进入「设置」→「路由设置」检查域名策略与预定义规则。若规则需要按目标 IP 判断，确认解析结果能被对应规则使用，避免域名先被错误出站解析。

5. 执行双网复测

   在两种网络下各进行 3 轮扩展检测，每轮间隔 15 秒。若只有移动网络出现本地解析器，应优先检查网络切换后的 VPN 重建与 IPv6 路由。

按应用代理是移动端高频遗漏点。检测浏览器不在代理列表中时，页面本身与 DNS 查询都会直接访问网络，结果自然保持本地状态。相反，如果浏览器已纳入 VPN，而另一个后台应用仍被排除，它产生的 DNS 请求可能继续走默认网络；此时系统级观察会看到旁路流量，但浏览器检测页未必能展示后台应用的查询。

v2flyNG 使用 v2fly 内核时，应以该内核实际接受的配置字段为准。若导入的订阅只包含节点协议、地址和端口，DNS 与路由通常仍由客户端本地设置决定，并不会从简单节点链接中自动获得完整策略。迁移配置时，应分别核对 VMess 或 VLESS 节点参数、传输设置、DNS 和路由规则，而不是只比较节点名称。

• Wi-Fi 正常、移动网络异常：重建 VPN 连接，检查 IPv6 可达性与移动网络提供的解析器是否仍被调用。
• 所有网络都出现本地解析器：检查浏览器是否被排除、远程 DNS 是否生效、客户端是否处于 VPN 模式。
• 检测结果正常但部分域名失败：检查域名策略、DNS 分流规则与解析器对目标域名的返回结果。
• 节点 IP 可连接但节点域名失败：为服务器域名保留独立且可达的引导解析，避免建立代理前产生循环依赖。

修复后验收：同时检查解析、路由与失败回退

修复完成后不要只看一次检测页。完整验收应覆盖冷启动、网络切换、节点切换和客户端退出四种状态。冷启动用于检查引导解析，网络切换用于检查 VPN 与路由表重建，节点切换用于检查不同服务器地址的解析路径，客户端退出则用于确认系统设置能够恢复。

建议保留一份简短验收记录。示例基线可以写成：v2rayN 7.14.x、Xray 内核、TUN 模式、远程 DNS 使用 HTTPS 连接、连续 3 轮检测未出现本地网络解析器、物理网卡观察期间没有持续直连 UDP 53。记录具体状态比只写“已修复”更便于之后比较客户端升级或规则调整造成的变化。

验收项	通过条件	失败后检查
冷启动解析	10 秒内完成节点域名解析并建立连接	引导 DNS、服务器域名与出站循环
连续检测	3 轮结果稳定，不出现本地网络解析器	浏览器安全 DNS、系统缓存与旁路应用
53 端口观察	物理网卡无持续直连 DNS 查询	TUN 捕获范围、UDP 与 TCP 规则
网络切换	重连后解析结果与切换前一致	VPN 重建、IPv6 路由与远程 DNS 可达性
退出恢复	系统 DNS 回到修改前基线	网卡手动 DNS 与残留代理设置

如果检测结果仍不稳定，按“应用入口、系统接管、内核 DNS、DNS 出站、最终路由”五层逐项缩小范围。不要同时改远程 DNS、域名策略、路由规则和工作模式；每次只改一项并重复相同测试，才能知道真正起作用的是哪一层。

常见问题