2026-08-04 · 故障排查 · 约 10 分钟

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

讲解 DNS 泄漏的成因与检测思路，并在 v2rayN 与 v2rayNG 中逐项调整 DNS、路由与系统代理设置，让解析请求统一经过代理链路。

本文速览

适合已经导入节点、网页能够访问，但不确定 DNS 是否绕过代理的用户。先区分网站出口、解析服务器与实际传输路径，再分别检查桌面系统代理和 Android VPN 接管范围，最后用浏览器测试、客户端日志与网络抓包交叉验证。本文不提供直接覆盖现有配置的通用 JSON，避免破坏订阅生成的出站与路由。

一、DNS 泄漏的判断边界

DNS 把域名转换为 IP 地址。网站连接经过代理，不代表此前的域名查询也经过代理：浏览器、操作系统、客户端内核都可能发起解析。本文所说的泄漏，是原本计划经代理处理的域名查询，实际交给了本地网络或其他非预期解析路径。如果境内域名按既定规则直连并使用本地 DNS，那属于分流策略，不应仅凭“出现本地解析器”就判定失败。

应用域名请求 解析入口接管 DNS 规则选择 查询出站传输 目标连接建立

V2Ray、Xray 是内核；v2rayN 是桌面图形客户端；v2rayNG 是使用 Xray 内核的 Android 客户端；v2flyNG 则使用 V2Fly 内核。界面上的 DNS 选项最终需要转换为所选内核的运行配置。VMess、VLESS 是代理协议，不会单独决定系统中所有程序的解析路径。

看到的现象能够说明什么还需确认什么
网站出口 IP 已改变本次网站连接使用了相应出口域名解析是否由本地网络完成
检测页显示公共解析器测试域名最终由该解析服务递归查询查询到解析器这一段是否经过代理
解析器与节点国家不同解析服务与网站出口位置不同是否涉及公共 DNS 的任播或不同出口
本地网卡出现 UDP 53有明文 DNS 查询离开设备查询域名是否属于允许直连的范围

二、建立基线：同一网络做三组对照

先记录当前节点、路由模式、浏览器安全 DNS、系统 DNS 和客户端运行模式。不要同时修改这些项目，否则结果变化后无法定位原因。测试使用同一台设备、同一个浏览器和同一网络，分别记录“客户端断开”“仅系统代理”“启用 TUN 或 VPN 接管”的结果；不具备某种模式时跳过，不要为了凑齐测试而叠加其他网络软件。

53
传统 DNS 常用 UDP/TCP 端口
443
DoH 常用 HTTPS 端口
10808
本地代理端口示例，以设置为准
  1. 取得直连基线。断开客户端，在 DNS 检测页运行测试，记录解析器名称、地址与时间。测试页通常通过随机子域名减少缓存干扰，但只覆盖当前浏览器的请求。
  2. 取得代理结果。连接节点，在相同检测页重新运行完整测试，而不是只刷新旧结果。同步记录网站出口 IP，区分连接出口变化与解析路径变化。
  3. 控制浏览器变量。临时关闭浏览器自带的安全 DNS，再测一次。若日常需要保留该功能，应恢复后重新验证其 HTTPS 连接是否也经过预期出站。
  4. 检查其他应用。浏览器通过测试后，再检查实际使用的软件。系统代理不保证覆盖命令行工具、自带解析器的程序或直接发送 UDP 的应用。

结论：解析器名称不是传输路径证据

如果只知道检测页显示了哪家 DNS，先不要更换节点。优先检查该查询是否从本地网卡直出，再决定修改接管范围还是 DNS 出站规则。

三、v2rayN：先确认接管，再设置 DNS

以下按常见中文界面说明，具体分组会随版本和所选内核变化。操作前记录 v2rayN 版本、内核类型并备份当前设置。桌面端的“设置系统代理”主要影响遵循系统代理的应用；TUN 才提供更广的网络接管能力，但仍要检查排除项和 DNS 接管规则。两种模式不要混为一谈。

  1. 核对本地入口

    打开「设置」→「参数设置」，检查本地监听端口。若实际端口为 10808，应用必须使用对应的协议与端口，不能把 SOCKS 入口直接当成 HTTP 入口；支持混合监听时以界面说明为准。

  2. 确认代理模式

    在主界面底部「系统代理」选择「自动配置系统代理」，随后检查系统中的代理地址与端口是否一致。需要覆盖不遵循系统代理的应用时，再考虑主界面的「启用 TUN」，并按提示授予所需权限。

  3. 检查 DNS 规则

    进入「设置」→「DNS 设置」。若当前内核或版本将此项放在参数设置中，使用对应 DNS 页面。检查代理域名所用的远程解析器，并确认到该解析器的连接走代理出站；不要只填写服务器地址就结束。

  4. 核对分流范围

    在路由设置中核对直连域名、代理域名和默认出站。临时切换为全局代理路由可以缩小排查范围，但它不能替代 DNS 接管，也不能证明系统中所有应用已经被捕获。

  5. 重启并复测

    保存后重启内核，确认启动日志没有配置错误，再重复同一组检测。若订阅更新后结果反复变化，检查 DNS 或路由是否被订阅、自定义配置重新生成，而不是连续叠加更多规则。

对于 macOS、Linux，系统代理的作用范围由桌面环境和应用实现决定，不应直接套用 Windows 的系统设置入口。无论平台如何，验证重点都是应用流量是否进入客户端、内核使用哪个 DNS，以及 DNS 查询最终选择了哪个出站。

四、v2rayNG：检查 VPN 范围与远程 DNS

Android 上连接成功后出现 VPN 标识，只说明 VPN 服务已经建立，并不保证每个应用都在处理范围内。分应用代理、绕过局域网、其他 VPN 服务和系统私人 DNS 都可能改变结果。v2rayNG 的具体字段随版本变化，下列步骤以设置页常见的「远程 DNS」「启用本地 DNS」标签为线索；不存在的选项不要用其他开关硬凑。

  1. 检查应用范围

    打开侧边菜单「设置」→「分应用代理」，核对当前是代理所选应用还是绕过所选应用。测试浏览器必须包含在代理范围内；排查时可暂时关闭分应用限制，并记录原来的名单。

  2. 配置解析入口

    在「设置」中找到 DNS 相关分组，检查「远程 DNS」；若有「启用本地 DNS」，先阅读选项说明再启用。这里的“本地”通常指客户端内部 DNS 处理，不等同于把查询交给运营商 DNS。

  3. 核对系统变量

    打开 Android 系统「设置」→「网络和互联网」→「私人 DNS」，记录当前状态。不同厂商路径可能不同，可在系统设置中搜索“私人 DNS”。对照测试时临时关闭，完成后恢复并再次验证。

  4. 重连并查看日志

    保存设置后断开、重新连接，在侧边菜单「日志」查看查询超时或出站失败。分别用 Wi-Fi 和移动网络重复测试，确认不是只有某一网络能够访问选定的解析服务。

如果同时启用了浏览器安全 DNS和系统私人 DNS，先一次只保留一个变量。DoH 使用 HTTPS，DoT 常用 TCP 853；两者提供查询传输加密，但是否经过代理仍由接管范围与路由决定。切换网络后仅能打开已访问的网站，也可能是缓存掩盖了解析故障，不代表配置已经稳定。

  • 使用全局代理路由作为对照后，记得恢复原先的分流规则，并重新验证代理域名与直连域名。
  • 局域网打印机、企业内部域名可能依赖本地 DNS，应单独保留明确规则，不要把所有解析器一律替换成公共服务。
  • v2flyNG 使用不同内核与界面实现，不应直接复制 v2rayNG 的运行配置；迁移时重新核对 DNS 字段与路由能力。

五、日志与抓包：定位请求在哪一层失败

先看失败发生在查询、连接还是监听阶段。下列片段可能出现在内核或底层网络错误中，完整前缀会因版本变化。它们都是排查线索，不能单凭一行日志认定发生 DNS 泄漏。

报错：context deadline exceeded

原因：操作在时限内未完成；出现在 DNS 查询附近时，可能是解析器不可达或查询出站有误。

解法：核对同一时间的目标地址与出站记录，先验证解析器的网络路径，再调整超时参数。

报错：no such host

原因：名称解析未得到可用结果，可能涉及域名拼写、上游返回不存在或过滤规则。

解法：确认失败对象是节点域名还是业务域名，再用独立解析路径交叉检查，不要直接改动所有路由。

报错：address already in use

原因：准备监听的地址或端口已被其他进程占用，客户端入口可能根本没有启动。

解法：检查占用进程或更换监听端口，并同步修改应用代理设置，然后重启内核确认监听成功。

Windows：查询系统 DNS 与清理缓存

在 PowerShell 中执行以下命令，分别查看系统网卡 DNS、清理系统解析缓存、测试命令行解析。最后一条通常使用系统配置的解析服务器，不会因为开启 HTTP 系统代理就自动改走客户端，因此它与浏览器结果不同并不矛盾。

Get-DnsClientServerAddress
Clear-DnsClientCache
nslookup example.com

检查明文 DNS 与 IPv6

具备抓包条件时，在物理网卡观察下面的过滤条件。先关闭无关应用，再触发一次新的域名查询。只看到 53 端口流量还不够，要结合查询名称和时间判断是否属于测试应用；没有 53 端口流量也不等于绝对安全，因为查询可能走加密 DNS 或命中缓存。

udp.port == 53 || tcp.port == 53
tcp.port == 853

六、防泄漏验收清单与回退方法

验收应围绕既定策略，而不是追求页面上只显示一个解析器。若目标是所有业务查询经过代理，就检查每个受管应用的解析入口和出站；若目标是国内外分流，就分别验证直连域名与代理域名。DNS 查询与网站连接可以采用不同策略，但必须是明确设计，而不是偶然绕过。

  • 配置生效：重启后内核正常运行，日志中没有 DNS 配置解析失败或监听失败。
  • 路径一致：测试浏览器位于接管范围内，远程 DNS 的连接命中预期代理出站。
  • 缓存排除：清理系统缓存或使用检测页新生成的查询，避免把旧结果当成当前配置。
  • 网络覆盖：切换 Wi-Fi、移动网络或桌面网络后再次测试，记录差异，不虚构单次结果的普遍性。
  • 启动可用：设备重启后首次连接也能解析节点地址，不依赖上一次连接留下的缓存。
  • 回退明确：保留原 DNS、路由与私人 DNS 设置；出现故障时先还原最近一次修改，再验证基本连接。

结论：一次只修正一条路径

网页可访问但解析路径异常时，先修正 DNS 接管和查询出站；节点域名都无法解析时，先恢复启动解析。两类问题分开处理，比同时更换协议、节点和全部 DNS 设置更容易得到可复现的结果。

分享排查信息时，保留客户端版本、内核、路由模式、错误时间与脱敏日志即可。订阅地址、节点凭据和完整运行配置可能包含访问权限，不应公开粘贴。需要继续定位时，可查看问题诊断，按启动、监听、连接、解析的顺序逐项排除。

下载v2rayN