故障排查 预计阅读 12 分钟

DNS 泄漏检测与修复实操:让域名解析和流量走同一条链路

讲清什么是 DNS 泄漏、为什么代理已连接仍会泄漏解析请求,给出在线检测方法与 v2rayN/v2rayNG 的 DNS 配置改法,逐项验证修复效果。

代理客户端显示连接成功，只能证明节点握手和部分出站流量可用，不能直接证明域名解析也进入了同一条代理链路。浏览器访问网站之前，通常需要先把域名解析成 IP 地址；如果这一步仍交给本地网络、路由器或运营商 DNS，访问内容虽然经过代理，查询过哪些域名的解析请求却可能从另一条路径发出。

排查 DNS 泄漏不能只看检测页面出现了哪个国家或地区，也不能把所有本地解析器都视为异常。需要同时确认应用流量接管方式、系统 DNS、浏览器安全 DNS、客户端远程 DNS 和路由规则，最后通过修改前后的对照结果判断链路是否真正收敛。

本文速览

本文适合已经能连接 VMess、VLESS 等节点，但 DNS 检测结果仍显示本地解析器、网页偶发解析失败或分流结果异常的用户。操作从建立检测基线开始，分别处理 v2rayN 与 v2rayNG，再用日志、系统命令和重复测试确认修复结果。

DNS 泄漏发生在哪一段链路

一次常见网页请求至少包含“应用发起域名请求、DNS 返回地址、应用连接目标地址、路由规则选择出站”几个阶段。系统代理主要接管支持 HTTP 或 SOCKS 代理的应用连接，操作系统产生的 UDP 53 查询不一定会自动进入代理。即使 Xray 内核配置了远程 DNS，如果应用仍直接调用系统解析器，内核也可能根本看不到这次查询。

TUN 模式通过虚拟网卡接管更广范围的 IP 流量，能够把不读取系统代理设置的进程以及 DNS 数据包纳入路由。Android 上的 v2rayNG 通常借助系统 VPN 接口完成类似接管。接管只是第一步，后续仍需确保 53、853 或 443 端口上的解析流量没有被直连规则提前放行。

应用查询域名 系统解析请求 客户端接管 DNS 规则匹配 代理链路出站
53
传统 DNS 的 UDP/TCP 端口
853
加密 DNS 的常见 DoT 端口
443
DoH 常用 HTTPS 端口
3 轮
基线、修复、重启后复测

浏览器内置的安全 DNS 是另一个变量。浏览器可能绕过系统 DNS，直接向指定 DoH 服务发送 HTTPS 请求；这类请求在检测页面上会显示为另一个解析服务。它是否泄漏取决于该 HTTPS 连接最终走直连还是代理，而不是取决于页面上是否出现了熟悉的 DNS 名称。

建立可重复的 DNS 检测基线

先不要急着改配置。记录修复前状态，才能区分真实改进和检测页面缓存。建议使用同一浏览器、同一网络、同一节点完成三轮测试，每轮之间关闭检测标签页并等待约 30 秒。标准测试用于快速观察解析器，扩展测试用于触发更多随机域名查询，更容易发现同时存在的本地 DNS 与远程 DNS。

  1. 记录当前模式

    记录客户端名称、核心类型、节点协议和接管模式。例如 v2rayN 7.x、Xray 核心、VLESS 节点、系统代理模式；不要只写“代理已开”。

  2. 暂退其他网络

    退出同时运行的其他代理、企业网络接入和独立 DNS 工具，避免多个虚拟网卡或本地监听端口共同影响结果。

  3. 检查浏览器 DNS

    在浏览器隐私或安全设置中记录“使用安全 DNS”的开关与提供方。首次基线可临时关闭该功能，用于判断系统与客户端路径。

  4. 执行扩展检测

    打开可信的 DNS 泄漏检测页面，完成标准测试和扩展测试，记录解析器名称、地址数量、地区及第一次查询耗时。

  5. 断开后对照

    断开客户端并刷新网络连接，再测试一次。若连接前后解析器完全一致，而网页出口地址明显变化，DNS 大概率没有跟随代理链路。

Windows 可用系统命令辅助确认当前网卡拿到的 DNS 地址。它只能说明系统准备向哪里查询，不能单独证明数据包最终经过哪个出站，但适合定位路由器地址、旧虚拟网卡和手动填写的解析器。

Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName example.com
ipconfig /flushdns

如果列表中同时出现物理网卡、虚拟网卡和已断开的旧适配器，先关注当前具有默认路由的网卡。修改设置后执行缓存清理，再重新解析随机域名；反复查询同一个域名可能直接命中系统、浏览器或客户端缓存，无法触发新的外部请求。

报错:DNS request timed out.

原因与解法:系统配置的 DNS 不可达，或 53 端口被当前网络阻断。先恢复为可访问的解析器，再检查 TUN 路由是否接管 DNS。

报错:server failed

原因与解法:解析器返回 SERVFAIL，常见于上游故障、域名校验失败或转发链配置错误。更换远程 DNS 后清理缓存并重新测试。

v2rayN 修复路径:系统代理与 TUN 分开处理

v2rayN 使用系统代理时，浏览器的 HTTP/HTTPS 请求通常进入本地代理端口，但 Windows DNS 仍可能直接发往网卡配置的解析器。常见本地监听组合是 SOCKS 10808 与 HTTP 10809，具体数值以「设置」→「参数设置」中的本地端口为准。端口能正常监听并不代表 UDP 53 已被接管。

如果目标只是让支持代理的浏览器使用指定解析路径，可以同时调整浏览器安全 DNS，并确认该 DoH 请求通过代理发送。如果目标是覆盖更多桌面程序、命令行工具和系统解析请求，应使用 TUN，并检查 DNS 劫持与路由规则。两种方案的覆盖范围不同，不应把系统代理模式的检测结果直接等同于 TUN。

  1. 确认核心类型

    进入「设置」→「参数设置」→「Core 类型」，确认当前配置使用的核心与节点协议兼容。修改核心后重启一次客户端，避免旧进程继续占用配置。

  2. 设置远程 DNS

    打开「设置」→「DNS 设置」，在远程 DNS 中填写明确的解析服务。可先使用 1.1.1.1 或 8.8.8.8 做单变量测试，确认稳定后再按网络环境调整。

  3. 启用 TUN 接管

    在主界面启用 TUN 模式，并允许创建虚拟网卡所需的系统权限。启用后确认虚拟适配器存在，默认路由没有被其他网络工具覆盖。

  4. 核对 DNS 分流

    检查路由规则中针对 DNS 服务器地址、UDP 53、TCP 853 和所用 DoH 域名的规则。预期走代理的查询不能被“局域网直连”或过宽的 IP 规则提前命中。

  5. 清缓存再重启

    关闭浏览器，执行 ipconfig /flushdns，重启 v2rayN 核心后再打开检测页面。用新的随机域名触发查询，避免读取旧缓存。

Xray 的 DNS 模块可以为路由判断解析域名，也可以把查询交给指定上游，但它不会凭空接管所有系统请求。只有请求进入内核，DNS 配置才有机会生效。若日志里只有目标连接记录而没有对应 DNS 查询，优先检查接管模式，不要反复更换上游地址。

报错:failed to lookup ip

原因与解法:内核无法从当前 DNS 配置取得节点或目标地址。检查服务器地址拼写、远程 DNS 可达性和 DNS 出站规则，然后重启核心。

报错:no such host

原因与解法:域名返回不存在或本地缓存保留了失败结果。确认订阅中的服务器域名完整，清理系统 DNS 缓存后改用另一远程解析器复测。

报错:context deadline exceeded

原因与解法:上游 DNS 在超时时间内没有响应，常见于 DoH 连接被直连规则阻断。检查 443 端口出站和域名规则，必要时先换成普通远程 DNS 定位。

v2rayNG 修复路径:VPN 接管与私人 DNS 协同

v2rayNG 使用系统 VPN 接口接管流量时，DNS 通常比桌面系统代理更容易进入隧道，但仍可能受到“私人 DNS”、分应用代理、绕过局域网和路由规则影响。v2rayNG 使用 Xray 内核时，远程 DNS、域名策略和 FakeDNS 属于不同配置项；排查泄漏时先建立普通远程 DNS 的稳定基线，再决定是否启用 FakeDNS。

系统私人 DNS 通常使用 DoT，也就是 TCP 853。若私人 DNS 保持指定主机名，系统会继续尝试连接该服务。该连接是否经过当前节点取决于 VPN 接管范围和分流规则。为了隔离变量，首次排查可把系统「设置」→「网络和互联网」→「私人 DNS」暂时设为“自动”或“关闭”，完成 v2rayNG 验证后再逐项恢复。

  1. 检查运行模式

    确认 v2rayNG 已显示 VPN 连接状态，状态栏存在系统 VPN 标识。若只修改配置但没有启动连接，远程 DNS 设置不会接管其他应用请求。

  2. 填写远程 DNS

    打开左上角菜单「设置」→「远程 DNS」，填写一个明确可达的解析地址。测试阶段不要同时填写多个行为未知的上游，以免结果难以归因。

  3. 核对本地 DNS

    在「设置」中检查「本地 DNS」与「启用本地 DNS」。本地 DNS 主要处理客户端侧查询入口，远程 DNS 决定进入内核后的上游解析路径，两者不能混为一项。

  4. 关闭分应用绕过

    排查阶段暂时关闭分应用代理，或确保浏览器和检测工具位于代理列表内。被排除的应用会直接使用物理网络，检测结果自然与节点出口不同。

  5. 重连并复测

    停止连接，等待约 10 秒后重新启动。强制结束浏览器再打开，完成两轮扩展检测，并与移动网络和无线网络分别记录的结果对照。

v2rayNG、v2flyNG 的内核实现不同，设置名称和可用能力也可能随版本调整。v2rayNG 的 Xray DNS 配置不能原样当作 v2flyNG 的 v2fly 内核配置使用。迁移订阅只会导入节点信息，不会自动复制设备上的 DNS、路由与分应用设置，换客户端后应重新建立基线。

报错:Unable to resolve host

原因与解法:应用或内核未获得域名结果。先确认 VPN 已连接，再检查远程 DNS、系统私人 DNS和当前网络是否阻断对应端口。

报错:network is unreachable

原因与解法:DNS 上游被路由到不可用接口，常见于无线网络切换后旧 VPN 路由未刷新。停止 v2rayNG，切换一次网络并重新连接。

复测结果怎样才算修复完成

修复完成不要求检测页面只出现一个地址。公共 DNS 服务可能使用任播，同一服务在不同查询中返回多个出口；部分检测页面还会把解析器前端和实际递归节点分开显示。更可靠的标准是：连接客户端后不再出现家庭路由器、当前网络运营方或明确不在预期中的本地解析器，并且重启客户端、浏览器和设备后结果保持一致。

还要验证分流。若国内域名按规则直连、其他域名走代理，DNS 也可能按域名分组使用不同上游，这属于设计结果，不应简单追求“全部只有一个解析器”。关键是每组查询与对应出站一致，避免先用本地 DNS 得到受网络影响的地址，再把连接交给代理。

出口地址变了，DNS 结果为什么没变？

系统代理只接管了网页连接，系统 DNS 仍从物理网卡发出。v2rayN 可改用 TUN 并检查 DNS 路由；修改后清理缓存再测。

检测页面显示两个远程解析器正常吗？

可能正常。确认两者都属于所选上游或其递归节点，并重复三轮测试。若断开代理后其中一个仍固定出现，再检查本地网络配置。

开启 FakeDNS 就一定能解决吗？

不能直接下结论。FakeDNS 用假地址保存域名映射，适合与 TUN 和域名分流配合，但不修复未被接管的查询。应先确认 DNS 数据包进入内核。

换了节点还需要重新检测吗？

需要。不同节点可能命中不同路由、出口地区和 DNS 上游。至少执行一次标准测试；若解析器变化异常，再执行扩展测试。

网页正常但订阅更新失败怎么办？

订阅更新进程可能使用独立网络路径。检查订阅设置是否允许通过代理更新，并在核心日志中查找域名解析超时或连接超时记录。

最终验收清单

  • 客户端重启后节点可正常连接，VMess 或 VLESS 握手日志中没有持续解析错误。
  • 标准测试与扩展测试均未出现当前家庭路由器或非预期运营方解析器。
  • Windows 的物理网卡、TUN 虚拟网卡和旧虚拟适配器不存在相互冲突的默认路由。
  • Android 的私人 DNS、分应用代理和 v2rayNG 远程 DNS设置符合当前接管目标。
  • 浏览器安全 DNS 的开关已经记录，恢复后再次确认其 HTTPS 请求走预期出站。
  • 切换节点、切换无线网络与移动网络后至少各复测一次，结果没有回到本地解析路径。

如果复测仍不稳定，按“应用是否被接管、DNS 请求是否进入内核、上游是否可达、路由是否命中、缓存是否清理”的顺序检查。不要同时修改 TUN、DNS、路由和浏览器四组设置；每次只改变一个变量并保存结果，才能定位真正影响链路的配置。

下载客户端