risk/security · 集群 A · 隐私与日志 · 4/6

DNS 泄露是什么:成因、自查方法与修复思路

发布时间 待核实核实日期 待核实最近更新 待核实测试状态 Not Tested
Answer First · 核心结论

DNS 泄露是指你的域名查询没有经过代理,而是直接发给了本地运营商或系统默认的 DNS 服务器,导致本地网络能看到你访问了哪些域名。它多数源于客户端模式和 DNS 设置,而不是服务商问题。自查可以对比「DNS 检测页显示的解析服务器」与「你预期的服务器」是否一致,修复通常从开启 TUN 模式或统一 DNS 设置入手。

什么是 DNS 泄露

DNS 泄露指的是:你以为所有请求都经过了代理,但域名查询这一步却绕过代理,直接发给了本地运营商或系统默认的 DNS 服务器。结果是,本地网络虽然看不到你访问的内容,却能看到你查询了哪些域名。

访问一个网站之前,设备要先把域名翻译成 IP 地址,这一步就是 DNS 查询。传统 DNS 查询是明文的,经过谁就被谁看到。所以「查询经过哪里」决定了「谁知道你要访问哪里」。DNS 本身的原理和污染问题可以参考 网络原理与排障。

DNS 泄露的常见成因

直接回答:绝大多数 DNS 泄露来自客户端模式与 DNS 设置的组合问题,服务商侧通常无法帮你解决。

成因 发生机制 典型场景
系统代理模式的局限 系统代理只影响遵循代理设置的应用,部分应用和系统服务会直接解析域名 命令行工具、部分桌面应用、游戏客户端
浏览器自行解析 浏览器在发送请求前先在本地解析,或启用了独立的安全 DNS 设置 浏览器设置里指定了某个 DNS 服务
IPv6 未接管 客户端只处理 IPv4,系统通过 IPv6 向运营商 DNS 查询 运营商下发了 IPv6 地址的家庭宽带
分流规则遗漏 规则把未匹配的域名交给本地 DNS 解析后再判断 规则集过旧或自定义规则有误
多网卡或 VPN 冲突 其他虚拟网卡或软件修改了系统 DNS 同时运行多个网络工具

其中第一条最常见。系统代理本质上是「建议应用走代理」,是否遵守由应用决定;TUN 模式则是在网卡层面接管,覆盖范围更广。两者的区别可以参考 桌面客户端专题。

自查流程

结论:自查的核心是比较「实际处理你 DNS 查询的服务器」和「你预期的服务器」是否一致,不需要特别的工具,网页检测加上客户端日志就够。

开始
 │
 ├─ 1. 关闭代理,打开任一 DNS 泄露检测页,记录显示的 DNS 服务器归属(通常是本地运营商)
 │
 ├─ 2. 开启代理(你平时使用的模式),刷新检测页
 │
 ├─ 3. 对比结果
 │     ├─ 显示的仍是本地运营商 ──> 可能存在泄露,进入排查
 │     └─ 显示的是代理侧或你指定的服务器 ──> 浏览器层面基本正常
 │
 ├─ 4. 用命令行工具或其他应用访问一个需要代理的域名,查看客户端日志是否记录到该查询
 │
 └─ 5. 如运营商下发 IPv6,单独确认 IPv6 DNS 是否被接管

注意几点:

  • 检测页本身是第三方网站,选择你认为可信的即可,不要在检测页输入任何账号信息;
  • 浏览器检测只能代表浏览器,系统其他应用需要通过客户端日志或抓包确认,日志与抓包方法见 网络原理与排障;
  • 检测结果显示的是 DNS 服务器归属,判断时看的是「是否为本地运营商」,而不是具体的 IP。

修复思路

直接回答:修复按「先模式、再 DNS、后 IPv6」的顺序进行,每改一项都重新自查一次,避免一次改太多不知道哪项生效。

  1. 评估是否需要 TUN 模式:如果泄露来自不遵守系统代理的应用,开启客户端的 TUN 模式通常能覆盖;开启后注意客户端的 DNS 劫持或虚拟 DNS 选项是否启用。
  2. 统一 DNS 设置:检查客户端配置中的 DNS 部分,确认需要代理的域名由代理侧解析;同时检查浏览器是否单独指定了安全 DNS,必要时让它跟随系统。
  3. 处理 IPv6:如果客户端不接管 IPv6,可以在客户端中开启 IPv6 支持,或在不需要时于网卡层面关闭 IPv6,IPv6 相关原理见 网络原理与排障。
  4. 更新规则集:过旧的分流规则可能遗漏新域名,订阅与规则更新见 订阅管理专题。
  5. 排除冲突软件:关闭其他 VPN 或网络加速工具后再测试。

修复后的副作用

结论:接管 DNS 会改变解析路径,可能带来访问变慢或部分境内网站解析异常,需要在隐私与体验之间找平衡。

调整 可能的副作用 缓解办法
开启 TUN 模式 部分应用兼容性问题、局域网访问异常 为局域网与特定应用添加直连规则
全部域名走代理解析 境内网站解析到境外节点,访问变慢 境内域名按规则直连并使用本地 DNS
关闭 IPv6 部分仅支持 IPv6 的服务不可用 视需要在客户端中开启 IPv6 支持

境内域名按规则直连并使用本地 DNS,是有意的分流设计,不算泄露。真正需要避免的,是本该走代理的域名被交给了本地 DNS。

如果修复后出现连接失败或速度问题,可以转到 故障排查专题 按分层方法定位。

移动端的情况有什么不同

结论:移动端客户端大多以系统 VPN 的方式工作,覆盖范围通常比桌面端的系统代理更广,但仍可能因为设置而出现泄露。

需要留意的几种情况:

  • 私人 DNS 或加密 DNS 设置:部分手机系统允许设置全局的私人 DNS,它可能优先于客户端的 DNS 处理,造成查询绕过代理;
  • 按应用分流:如果客户端只让部分应用走代理,其他应用的查询自然走本地 DNS,这属于设计而非错误,但要清楚哪些应用在名单内;
  • 网络切换:在移动网络与无线网络之间切换时,客户端重连前的短暂时间里可能出现请求直连。

移动端的自查方法与桌面端相同:用浏览器打开检测页对比结果,再结合客户端日志确认。移动客户端的设置可以参考 移动客户端专题。

DNS 泄露与其他泄露的关系

直接回答:DNS 泄露只是「请求绕过代理」的一种,另一种常被提到的是 WebRTC 泄露,两者成因不同,需要分别检查。

DNS 泄露暴露的是域名,WebRTC 泄露可能暴露真实 IP,详见 WebRTC 泄露真实 IP 的原理与防护。即使两者都修复了,服务商依然能看到你的连接元数据,这一点见 机场服务商能看到你的哪些数据。

使用代理服务时请遵守所在地法律法规。如果你还在选择客户端,可以先看 客户端教程;比较品牌时,可以在 机场品牌库 查看各品牌资料标注的客户端类型。

常见问题

DNS 泄露会暴露什么?

主要暴露你查询过哪些域名,即访问了哪些网站,查询方通常是本地运营商或系统配置的 DNS 服务器。它一般不暴露页面内容,但域名列表本身就能反映大量行为信息。

为什么开了代理还会 DNS 泄露?

常见原因有:系统代理模式下部分应用不走代理、浏览器或系统自行发起 DNS 查询、IPv6 DNS 未被接管、分流规则把查询交给了本地 DNS。这些都属于配置层面的问题。

TUN 模式能解决 DNS 泄露吗?

TUN 模式会在系统层面接管流量,通常配合客户端的 DNS 劫持或虚拟 DNS 功能,能显著减少泄露。但仍需检查客户端 DNS 设置与 IPv6 处理,开启后应重新做一次自查。

分流规则下境内域名走本地 DNS 算泄露吗?

按设计让境内域名直连并使用本地 DNS,属于有意的分流行为,不算配置错误。需要关注的是本应走代理的域名是否也被交给了本地 DNS。

信息来源与更新时间

信息来源
品牌清单资料(品牌公开信息整理)
测试范围
本站未进行测速与解锁实测,所有能力描述均为资料声明或未测试状态。
发布时间
待核实
核实日期
待核实
最近更新
待核实

字段含义与数据状态见 字段说明;核查进度见 品牌动态与核查日志。