DNS 泄漏到底是什么
DNS 泄漏，指的是设备在已建立加密隧道之后，部分域名解析请求并未经过隧道，而是以明文形式直接发送给本地网络出口或运营商的 DNS 服务器。很多人默认客户端已连接，域名解析也会一并被保护，但解析路径和传输路径其实是两套独立的路由逻辑，二者一旦不一致，DNS 泄漏就会发生——这不是加密强度被削弱，而是解析器绕开了隧道网卡，是一处路由疏漏。
DNS 泄漏是怎么发生的
要理解 DNS 泄漏，需要先弄清楚一次普通的域名解析请求究竟经过了哪些环节。应用发起访问时，并不会直接拿到目标服务器的 IP 地址，而是先向解析器发出查询，解析器再决定把这次查询转发给谁。如果这一步的转发目标始终固定为隧道内的远端 DNS，解析请求就会跟随其他流量一起被加密；但只要中间任何一个环节出现路由优先级错乱，请求就有可能被本地网卡直接送出隧道之外，变成一次不受保护的明文查询。
域名解析请求实际走的是哪条路径
多数操作系统在存在多张网络接口时，会依据路由表和接口优先级决定解析请求由哪张网卡发出，而不是简单地跟随应用层的隧道连接状态。当隧道网卡的优先级没有被设置为最高，或者系统在建立隧道前后没有及时刷新解析器列表，域名解析请求就可能继续沿用连接隧道之前的旧路径，直接从本地物理网卡发出。这种错位往往是静默发生的，应用界面通常不会给出任何提示，用户很难仅凭连接状态判断解析路径是否已经真正切换。
系统级 DNS 缓存与默认解析器优先级
操作系统和浏览器都会维护自己的 DNS 缓存，目的是减少重复查询带来的延迟。常见观测值显示，操作系统对普通 A 记录的默认缓存时间大多落在几分钟到几十分钟这一参考区间，浏览器的预解析缓存则通常更短。问题在于，如果这些缓存是在隧道建立之前生成的，记录的解析器地址仍然指向本地默认网络的 DNS，隧道建立后系统未必会主动清空旧缓存，于是后续请求会优先命中缓存里的旧解析器，而不是隧道内的新解析器，形成一种不容易被察觉的 DNS 泄漏。
VPN 已经连接，DNS 请求为什么还会走明文
不少用户的疑问是，客户端已经显示连接成功，为什么域名请求还会走明文。答案通常出在代理模式和网络协议栈这两个维度上。全局代理和分应用代理对解析路径的接管程度并不相同，而 IPv4 与 IPv6 双栈环境又让路由判断多了一层复杂度，任何一个维度处理不到位，都会让 VPN DNS 泄漏成为现实——DNS 请求明文直接暴露给本地网络，而不只是理论上的边缘情况。
分应用代理与全局代理的解析差异
全局代理模式下，系统级的默认路由通常会被整体接管，解析请求相对容易跟随隧道；但在分应用代理模式下，只有被明确加入列表的应用流量才会进入隧道，其余应用包括部分系统组件仍然复用系统默认解析器。如果域名解析这一环节没有被识别为需要跟随隧道的流量类型，即便目标应用本身走了隧道，它发出的域名请求也可能被系统解析器接管后直接送到隧道之外，这是分应用模式下最容易被忽视的一类泄漏诱因。
IPv6 双栈环境下的解析盲区
相当一部分隧道方案主要针对 IPv4 流量做了路由接管，而本地网络如果同时启用了 IPv6，设备在解析域名时可能优先尝试 IPv6 地址对应的查询请求，这部分请求未必会被同一套隧道规则捕获。一旦发生这种情况，即使 IPv4 流量已经被完整送入隧道，IPv6 路径上的域名解析仍然可能以明文形式暴露出去。这也是为什么部分自查工具会同时给出 IPv4 与 IPv6 两组检测结果，而不是只看一个方向。
DNS 泄漏与 DNS 劫持有什么区别
DNS 泄漏和 DNS 劫持经常被放在一起讨论，但两者发生的位置和性质并不相同。DNS 泄漏是解析请求本该进入隧道却没有进入，内容本身没有被篡改，只是暴露了曾经请求过哪些域名这一事实；DNS 劫持则是解析请求被中间环节拦截，并返回了错误或被替换的结果，用户可能被引导到并非预期的服务器。把两者区分开，有助于判断该从路由配置入手排查，还是该怀疑解析结果本身的可信度。
| 对比维度 | DNS 泄漏 | DNS 劫持 |
|---|---|---|
| 问题性质 | 解析请求绕开隧道，路径错位 | 解析结果被篡改或替换 |
| 用户可感知程度 | 界面通常无提示，需要主动检测 | 访问结果异常，相对容易察觉 |
| 常见诱因 | 分应用代理、缓存未刷新、双栈遗漏 | 中间节点篡改响应、解析器被替换 |
| 典型影响 | 访问记录可能被本地或运营商 DNS 日志留存 | 被引导至错误或不可信的服务器 |
| 排查思路 | 核对解析路径与隧道网卡是否一致 | 核对返回的 IP 是否与目标服务器匹配 |
两者在排查思路上的不同起点
排查 DNS 泄漏，重点是确认解析请求究竟从哪张网卡发出、最终提交给了哪一个解析器；排查 DNS 劫持，重点则是核对拿到的解析结果是否可信，是否与目标服务器的真实地址一致。两条排查路径使用的工具和思路并不完全重合，如果不先做区分，很容易把一次简单的路由配置问题，误判成更复杂的解析安全事件，浪费不必要的排查时间。
如何自查 DNS 泄漏
判断自己是否存在 DNS 泄漏，并不需要专业的网络背景，几个简单步骤基本可以完成初步自查。核心思路是对比连接隧道前后，解析请求所使用的服务器地址、归属地和运营商信息是否发生了变化。如果连接隧道之后，检测结果里的 DNS 服务器仍然指向本地运营商，而不是隧道对应的远端节点，基本可以判断存在泄漏，需要进一步检查代理模式或系统网络设置。
- 在浏览器中访问在线 DNS 泄漏检测页面，记录返回的解析服务器归属地与运营商名称
- 对比检测结果中的运营商信息，与本地网络实际使用的运营商是否一致
- 在系统网络设置里确认 DNS 服务器地址，核实是否已被客户端接管为隧道内地址
- 检查浏览器是否单独开启了安全 DNS 选项，并确认其指向的解析服务商是否符合预期
- 在分应用代理模式下，单独选取一个未加入代理列表的应用做对照测试
- 断开并重新建立隧道连接后重复以上步骤，排除缓存造成的短暂误判
开发者视角下的解析记录暴露风险
对经常写代码的用户来说，DNS 泄漏还有一层容易被忽视的影响。开发过程中频繁请求的第三方 API 域名、内部使用的私有 npm 或 pip 镜像域名，一旦解析请求没有进入隧道，就可能被记录在本地网络或运营商的 DNS 日志里。这些域名往往能间接反映团队正在集成哪些服务、依赖哪些内部资源，对个人而言暴露的是使用习惯，对团队而言暴露的则可能是技术选型和协作关系的一部分，是日常开发中容易被忽略、但值得纳入自查范围的一类信息暴露。
总结
DNS 泄漏的根源是解析路径与隧道路径出现错位，而不是加密强度不够，厘清成因才能对症排查代理模式与双栈配置。定期自查解析路径，是保持连接可信的基础习惯，NasaCode 在节点接入与客户端配置上持续关注这类细节。
