代理节点显示已连接，不代表所有域名查询都进入了代理链路。浏览器、系统服务和普通应用在访问网站前通常先把域名交给 DNS 解析；如果这一步仍由当前网络的默认解析器完成，网页流量随后才走 VMess、VLESS 等代理出站，就形成了常说的 DNS 泄漏。排查时应把“域名由谁解析”和“网页数据从哪里出站”分成两条链路观察，不能只看出口地址。
本文适合已能连接节点、但检测页仍出现本地运营网络 DNS，或切换 TUN 后遇到域名超时的 v2rayN、v2rayNG 用户。完成检查后，可以判断结果是不是泄漏，统一远程 DNS 与 DNS 出站，并用两轮对照测试确认修复是否生效。
DNS 泄漏的链路与判断边界
一次常规访问可以拆成域名查询、地址返回、路由匹配和代理出站四个环节。系统代理主要接管支持代理设置的应用流量，未必自动接管系统发往 UDP 53 端口的查询。TUN 模式则能在虚拟网卡层捕获更广的连接，但仍要提供明确的 DNS 规则，否则查询可能被错误送到直连出口，或者在本地 DNS 与远程 DNS 之间循环。
真正需要关注的是解析器归属是否符合当前配置。例如，客户端明确指定远程 DNS，经代理访问检测页后仍反复显示当前宽带或移动网络提供的解析器，就应继续检查。相反，检测结果出现多个不同城市并不必然表示泄漏：公共 DNS 可能采用任播节点，检测站也可能把同一服务识别成不同机房。
- 系统代理场景：浏览器网页可能经过本地 HTTP 或 SOCKS 端口，但其他应用的 UDP 53 查询仍可直连。
- TUN 场景：应同时核对虚拟网卡、DNS 劫持、路由规则和远程 DNS，单独打开开关并不足够。
- 浏览器加密 DNS：浏览器自带解析设置可能绕过客户端方案，使测试结果与系统配置不一致。
- 缓存场景：系统、浏览器和客户端都可能保存旧答案，修改配置后立即刷新一次通常不能得出结论。
在线检测：先做基线，再做代理对照
检测前先关闭会改变网络路径的其他代理程序，只保留一个待测客户端。准备两个结果：未连接代理时的基线，以及连接节点后的对照。推荐分别执行标准测试与扩展测试；扩展测试通常会连续发起多组随机子域名查询，更容易暴露仍在直连的解析器。
- 断开 v2rayN 或 v2rayNG，记录当前出口地址、DNS 服务名称、国家或地区以及检测到的服务器数量。
- 清理 DNS 缓存，再关闭并重新打开浏览器，避免旧查询结果直接命中。
- 连接一个稳定节点，确认普通网页可以访问，再执行第一轮标准检测。
- 执行扩展检测，等待所有查询完成，不要只根据页面刚打开时的第一条记录判断。
- 间隔 30 秒再测一次，对照两轮结果是否稳定；偶发出现一条旧记录时，应再次清缓存复测。
| 观察结果 | 常见含义 | 下一步 |
|---|---|---|
| 仅出现配置的公共 DNS | 解析链路基本符合预期 | 再测浏览器与其他应用 |
| 出现基线中的本地解析器 | 可能仍有查询直连 | 检查 DNS 捕获与出站规则 |
| 不同浏览器结果不一致 | 浏览器解析策略可能独立生效 | 统一浏览器加密 DNS 设置 |
| 检测页超时但网页正常 | 随机子域名查询可能被阻断 | 查看核心日志中的 DNS 超时 |
一个可复现的实测记录应包含时间、客户端版本、工作模式和结果数量。例如：v2rayN 7.15.4，系统代理模式，未连接时检测到 2 个本地解析器；连接后仍出现同样的 2 个解析器。切换 TUN 并重启核心后，两轮扩展检测均只出现 1 组远程解析服务。这样的前后对照比截图中的单次结果更有价值。
结论:判断泄漏要看“基线解析器是否重现”
服务器数量和地理位置只能辅助判断；最直接的信号，是代理连接后仍稳定出现断开代理时记录的同一组本地 DNS。
v2rayN：远程 DNS、DNS 出站与 TUN 配置
以下步骤以 v2rayN 7.15.4 的界面为例。不同 7.x 小版本的菜单文字可能略有调整，但操作目标不变：给 Xray 内核指定远程解析器，让 DNS 查询匹配专用出站，并在需要覆盖非代理感知应用时启用 TUN。修改前先通过「服务器」→「导出所选服务器」或配置备份功能保存当前可用设置。
步骤一：确认本地监听与系统代理
- 打开「设置」→「参数设置」，记录本地混合监听端口。常见默认值为
10808，若已修改，以界面显示为准。 - 检查端口未被其他程序占用，然后回到主界面选择「自动配置系统代理」。
- 打开核心日志，确认入站监听已经启动，没有出现 bind 或 access denied 一类错误。
- 先在系统代理模式完成一次检测。如果浏览器正常而其他应用仍泄漏，再进入 TUN 配置，不要同时改动全部选项。
步骤二：指定远程解析器
进入「设置」→「DNS 设置」，选择当前使用的 Xray DNS 配置。远程 DNS 可以使用支持加密查询的地址，也可以使用普通 IP 解析器；关键是后续路由必须让该查询按预期走代理出站。下面是便于理解字段关系的示例，实际保存时应以客户端生成结构为准。
{
"dns": {
"hosts": {
"dns.google": "8.8.8.8"
},
"servers": [
{
"address": "https://1.1.1.1/dns-query",
"domains": [
"geosite:geolocation-!cn"
]
},
"223.5.5.5"
],
"queryStrategy": "UseIP"
}
}queryStrategy 控制返回地址族的偏好。网络只有稳定 IPv4 时可使用 UseIPv4；双栈环境可保留 UseIP。如果选择了无法正常连通的 IPv6 策略，表现往往不是“检测到泄漏”，而是域名解析变慢、日志出现超时或部分网站打不开。
步骤三：核对 DNS 出站与 TUN
- 在路由配置中确认 DNS 查询不会落入默认直连规则。使用专用 DNS 出站时，应让对应入站标签或端口规则指向该出站。
- 进入「设置」→「参数设置」→「TUN 模式」，启用虚拟网卡后重新启动核心。首次启用可能需要系统权限确认。
- 确认 DNS 劫持覆盖
53端口，并保留局域网需要的解析范围；企业内网域名不应盲目交给公网解析器。 - 观察日志中的 DNS 请求是否从远程服务器返回。完成后清缓存，再执行两轮扩展检测。
报错:failed to find an available destination
原因与解法:节点域名或 DNS 服务器地址没有得到可用结果。先检查节点地址拼写，把查询策略临时改为 UseIPv4，保存后重启 Xray 内核。
报错:lookup dns.google: i/o timeout
原因与解法:远程解析器连接超时，常见于 DNS 请求被错误分到直连出口。检查 DNS 出站标签与路由匹配顺序，再换一条稳定线路复测。
报错:bind: Only one usage of each socket address is normally permitted
原因与解法:本地监听端口已被占用。在「设置」→「参数设置」把混合端口从 10808 改为未占用端口，并同步更新系统代理后重启核心。
v2rayNG：安卓端 VPN DNS 与本地 DNS 配置
v2rayNG 通过系统 VPN 接口接管流量，DNS 是否进入隧道取决于 VPN DNS、本地 DNS、远程 DNS和路由配置。以下以 v2rayNG 1.10.16 为例。开始前先更新一次订阅并选中可用节点，确认核心类型为 Xray，再记录当前路由模式，避免把节点失效误判为 DNS 问题。
步骤一：填写 VPN DNS
- 进入右上角菜单的「设置」→「VPN DNS」，填入计划使用的解析器地址，例如
1.1.1.1。 - 进入「设置」→「远程 DNS」，配置用于代理域名查询的服务器；使用加密 DNS 地址时，确保其域名本身可以完成初始解析。
- 按网络环境检查「域名策略」。仅有稳定 IPv4 时优先使用 IPv4，避免不可达的 AAAA 地址拖慢连接。
- 返回主界面，断开后重新连接，使 VPN 接口和 DNS 参数重新创建。
步骤二：决定是否启用本地 DNS
「启用本地 DNS」的作用不是简单地把所有查询留在本机，而是让客户端按配置处理应用请求，再选择远程或直连解析器。启用后应同时核对国内 DNS、远程 DNS 和域名规则。若只打开开关却保留冲突的路由，可能出现同一域名先后请求两个解析器的情况。
| 配置项 | 建议检查值 | 异常表现 |
|---|---|---|
| VPN DNS | 填写一个当前网络可达的地址 | 连接后全部域名无法解析 |
| 远程 DNS | 与代理域名规则配套 | 检测结果仍出现本地解析器 |
| 域名策略 | 与实际 IPv4、IPv6 连通性一致 | 首开网页等待 5 至 10 秒 |
| 路由模式 | 测试阶段保持规则稳定 | 切换模式后结果无法对照 |
完成设置后，先断开连接 10 秒，再重新启动。进入核心日志观察是否持续出现 DNS timeout。若网页可以打开，用同一浏览器连续执行两轮检测；随后再换一个普通应用访问新的域名，确认不是只有浏览器自己的加密 DNS 在生效。
修复后验证与常见异常
验证阶段不要继续修改节点、路由和 DNS。固定一条线路、一个浏览器和一组检测步骤，才能确认是哪项设置产生效果。建议把每次结果记录成“模式、解析器数量、是否出现基线解析器、首次打开耗时”四项。
- 清除系统 DNS 缓存。桌面端可重新连接网络或执行系统提供的刷新操作；安卓端可断开 VPN 后切换一次网络，再重新连接。
- 关闭浏览器全部窗口后重新打开，先访问一个此前没有打开过的域名，避免直接命中缓存。
- 执行标准检测和扩展检测，各做两轮，间隔至少 30 秒。
- 查看核心日志，确认没有连续的解析超时、循环查询或路由到错误出站的记录。
- 切换一个不同网络环境后重复测试。如果只有某一网络泄漏，应检查该网络的 DNS 劫持或 IPv6 路径。
报错:context deadline exceeded
原因与解法:加密 DNS 请求在超时时间内没有完成。先确认其地址能经当前代理出站访问，再减少并行配置的解析器数量，重启核心复测。
报错:network is unreachable
原因与解法:配置返回了当前网络不可达的地址族。把域名策略调整为与实际网络一致，并检查 TUN 路由是否错误接管局域网网段。
连接正常，为什么检测页还显示本地 DNS？
先关闭浏览器独立的加密 DNS，再清缓存复测。如果结果不变，检查 v2rayN 的 DNS 出站和 TUN 劫持，或 v2rayNG 的 VPN DNS 与远程 DNS 是否同时生效。
打开 TUN 后所有网页都提示找不到地址？
查看核心日志是否出现 DNS timeout，确认 53 端口捕获后有可用出站。v2rayN 还要检查虚拟网卡权限，修改后退出核心并重新启动。
检测到三个公共 DNS，是不是仍然泄漏？
不一定。对照未连接代理时的基线，只要没有稳定重现本地解析器，而且三个结果都属于配置使用的公共解析服务，就不能仅凭数量判定泄漏。
订阅更新成功，但节点连接时报域名解析失败？
订阅地址与节点服务器地址是两次独立解析。检查节点域名拼写、远程 DNS 可达性和域名策略，必要时先切到 UseIPv4，再重启内核。
浏览器检测正常，其他应用还需要检查吗？
需要。浏览器可能使用自己的加密 DNS。保持 TUN 连接，从其他应用访问一个新域名，同时查看核心日志中是否出现对应查询，才能确认系统范围的捕获结果。
配置取舍：分流、内网域名与稳定性
防止 DNS 泄漏不等于把所有域名强制交给同一个公网解析器。家庭存储、打印设备和企业内部服务可能依赖局域网 DNS；如果全部送往远程服务器，这些名称会解析失败。更稳妥的方式是按域名和网段分组：内网域名交给本地解析器，代理域名交给远程解析器，解析请求再由对应路由规则送到直连或代理出站。
- 为内网域名保留明确的本地解析规则，不使用宽泛规则覆盖全部后缀。
- GeoSite 规则负责域名集合匹配，GeoIP 规则负责目标地址匹配，两者不能代替 DNS 出站配置。
- VMess、VLESS 只描述节点连接方式，不会自动决定系统 DNS 由谁处理。
- v2rayN 适合先用系统代理做单应用验证，再用 TUN 扩大接管范围。
- v2rayNG 应把 VPN DNS、远程 DNS、域名策略和路由模式作为一组配置共同检查。
结论:先固定解析链路，再优化分流规则
先让两轮检测不再出现基线解析器，并确保日志没有超时；随后再加入国内外域名分流和局域网例外，排错路径会更短。
如果修复后首次解析从约 200 毫秒上升到数秒，重点检查远程 DNS 是否绕路、加密 DNS 地址是否需要重复解析，以及路由是否形成循环。稳定配置应同时满足三点：检测结果可重复、常用域名解析速度正常、切换网络后能重新建立正确的 DNS 路径。只追求检测页显示某个地区，而忽略超时与兼容性，会把泄漏问题变成连接故障。