V2Ray DNS 泄漏检测方法与 v2rayN 防泄漏设置

一、DNS 泄漏判断：先分清查询与连接

DNS 把域名转换为 IP 地址。网页连接走代理，并不代表前面的域名查询也经过代理。例如，应用先向路由器的 192.168.1.1:53 查询，再把得到的 IP 交给本地代理，页面能够打开，域名查询却已经交给本地网络。这才是需要排查的路径分离。

在线 DNS 检测通常让浏览器访问一批随机子域名，再由测试方的权威 DNS 观察谁来递归查询。页面显示的多为递归解析器或它的出口，不是直接展示电脑网卡发出的每一个数据包。解析器所在国家与代理出口不同，不能单独证明泄漏。

• 需要关注：要求代理的域名，仍稳定地由本地运营商递归解析；或者抓包发现相关明文查询从物理网卡直接发出。
• 未必异常：公共 DNS 使用任播，检测页把解析器标在另一个地区；同一服务显示多个解析出口。
• 分流例外：局域网名称、明确设为直连的域名使用本地解析，可能正是配置目标。先写清哪些域名必须远程解析。

二、在线检测：建立三组可复现对照

可在浏览器打开 dnsleaktest.com，先运行 Standard test，再用 Extended test 复查。检测页会接收测试相关的网络信息，不要在输入框中提交订阅地址、节点凭据或工作内部域名。以下是操作记录模板，不是本文实测结果。

1. 记录基线

   在可信网络中，先关闭主窗口的「启用 TUN」，再选择「系统代理」→「清除系统代理」。记录检测结果，注意这一轮访问会直接经过当前网络。

2. 固定变量

   固定一个可用节点与同一个浏览器配置。记录浏览器“安全 DNS”是否开启；比较阶段不要同时更换节点、解析器和路由规则。

3. 清理缓存

   用管理员 PowerShell 执行 Clear-DnsClientCache。完全退出并重新打开浏览器，减少浏览器缓存与连接复用干扰。

4. 分轮测试

   先测系统代理，再测 TUN。每种状态运行两轮检测，记录时间与解析器 IP；不要只截取国家标签，也不要把旧标签页结果当作新结果。

三、系统代理与 TUN：接管范围不同

v2rayN 的「系统代理」→「自动配置系统代理」主要影响遵循 Windows 代理设置的应用。它不是全系统 DNS 接管开关。应用可以忽略系统代理，也可以先通过 Windows 解析域名，再连接代理端口。使用 SOCKS 的应用还要检查是否选择了“通过代理解析域名”，不能只看代理地址填对了没有。

本文以 v2rayN 7.x 常见桌面界面为路径参考，后续版本可能调整标签。主窗口的「启用 TUN」负责开启虚拟网卡接管；具体 TUN 实现、DNS 劫持规则和路由行为取决于实际启动的内核。节点使用 Xray，不等于 TUN 层也由 Xray 提供，判断时应看启动日志。

• 启动前：退出其他会接管路由或 DNS 的网络工具；按客户端提示授予管理员权限，避免虚拟网卡或路由创建失败。
• 启动后：确认日志中没有权限、网卡创建或路由冲突报错。开关显示开启，只能说明界面状态，不能代替实际接管验证。
• DNS 接管：检查当前 TUN 配置是否将普通 UDP/TCP 53 查询交给内核处理。浏览器自行发出的 DoH 使用 HTTPS，不能靠捕获 53 端口自动识别。
• IPv6：若物理网络提供 IPv6，需确认 IPv6 路由同样被接管。只有 IPv4 测试通过，不能证明双栈应用都经过预期出口。

四、远程 DNS：配置解析器，也配置出站

在 v2rayN 打开「设置」→「DNS 设置」，先确认正在编辑的配置属于实际使用的内核。Xray 的 DNS 配置与 sing-box 的 DNS 配置不是同一种格式，不能把一个内核的 JSON 整段粘贴到另一个页面。自定义配置节点还可能绕过部分图形界面选项，应以实际生成并加载的配置为准。

远程解析可选择服务方提供的 DoH 地址，例如 https://1.1.1.1/dns-query。DoH 加密的是客户端到解析器这一段查询内容，并不自动保证连接经过代理。若隐私目标是让解析服务看到代理出口，就必须同时确认该 HTTPS 连接的出站，而不只是确认 URL 使用了 HTTPS。

若使用 Xray 内置 DNS 的普通 https:// 模式，应结合路由核对解析连接的出口；https+local:// 属于本地模式，不能当作“强制走代理”的替代写法。若使用 IP 地址形式的 DoH 端点，要确保服务证书确实覆盖该地址，不要通过关闭证书验证解决连接错误。

• 把远程 DNS 的精确目标匹配放在可能覆盖它的宽泛直连规则之前。例如选择上述端点时，应检查 1.1.1.1/32 最终匹配的出站。
• 本地域名可以使用独立解析规则，但不要把所有未知域名都交给本地解析作为默认兜底。
• 节点服务器是域名时，保留必要的启动解析，并区分“节点地址的引导查询”和“访问目标域名的查询”。前者出现本地请求不等于后者全部泄漏。

五、流量探测：恢复域名，不替代 DNS 接管

在「设置」→「参数设置」中查找“流量探测”相关选项。不同版本可能使用“开启流量探测”或“启用流量探测”标签。它可从 HTTP Host、TLS 握手等可见信息恢复目标域名，辅助路由匹配；它无法撤回应用已经向本地解析器发送的查询。

以下仅展示 Xray 入站中的探测字段，用于理解配置含义，不是完整配置文件，也不是可以直接粘贴到 sing-box DNS 设置中的内容。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"],
    "routeOnly": true
  }
}

• enabled：启用该入站的流量探测，前提是应用流量确实进入这个入站。
• destOverride：指定尝试探测的协议。没有可见域名信息的连接，不能保证恢复出域名。
• routeOnly：仅把探测结果用于路由，不把原目标地址直接替换为探测域名。它不是 DNS 加密选项。

浏览器安全 DNS 同样要单独核对。Chrome 可从「设置」→「隐私和安全」→「安全」查看“使用安全 DNS”；Edge 可在设置中搜索“安全 DNS”。排查时先关闭它做一轮对照，再按最终策略决定是否启用。最终验收必须使用准备长期保留的状态，不能测试时关闭、测试后开启却不复测。

六、日志报错与命令行定位

内核日志中的错误只说明某一步失败，不等于已经发生泄漏。应结合目标地址、时间与出站标签定位。下面列出常见错误片段；前后缀可能随内核版本变化，不要要求整行日志与示例完全一致。

需要判断 Windows 当前采用的 DNS 地址时，可在 PowerShell 执行以下命令。它们用于查看网卡配置和验证系统解析，不是代理浏览器的等价测试。尤其是手动指定解析器的查询，在未被 TUN 接管时可能直接发往该地址。

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientServerAddress -AddressFamily IPv6
Clear-DnsClientCache
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA

网卡列表里保留路由器 DNS，并不单独证明泄漏，因为 TUN 可能拦截发往它的请求。反过来，列表显示公共 DNS 也不能证明查询经过代理。需要进一步抓包时，在物理网卡检查 UDP/TCP 53 与 TCP 853 的直连流量；HTTPS 上的 DoH 无法仅凭端口 443 与普通网页区分，还要结合目的地址和内核日志。

七、验收清单：把日常状态一起测完

完成修改后保存设置，按客户端提示重启内核；涉及 TUN 路由或虚拟网卡时，重新开关 TUN。最终验收不只检查一个网页，还应覆盖重新启动、网络切换与 IPv6。一个检测页只能说明该次浏览器请求的表现，不能替所有后台程序作保证。

• 浏览器：按日常安全 DNS 设置运行两轮扩展检测，公网出口与解析器符合预期，本地运营商解析器不再出现在要求远程解析的测试链路中。
• 系统应用：用实际需要代理的程序验证，确认它遵循系统代理，或已被 TUN 捕获；不要把浏览器通过当成所有程序通过。
• 双栈网络：分别检查 A 与 AAAA 解析及 IPv4、IPv6 连接，确认没有只接管一半流量。
• 故障场景：临时停用节点，观察远程解析失败后是否转为不符合策略的本地查询；测试结束立即恢复节点。
• 重启恢复：重启客户端后再次检测。切换无线网络或有线网络后，核对 TUN 路由与 DNS 接管是否仍有效。

稳定方案由三部分组成：应用流量进入预期入口，域名查询使用预期解析器，解析连接经过预期出站。TUN、DoH 与流量探测分别处理不同环节。把三者逐项验证，比反复更换公共 DNS 地址更容易定位问题，也更便于以后升级客户端时回归检查。