DNS 泄露详解：原理、检测方法与防范

"我明明开了代理，为什么别人还能知道我访问了哪些网站？"

这个问题的答案十有八九是：你的 DNS 请求没走代理。这叫 DNS 泄露（DNS Leak）。

先理解 DNS：互联网的通讯录

你访问 www.example.com 时，浏览器做的第一件事是问 DNS 服务器："这个域名的 IP 是多少？"

DNS 服务器（通常由运营商分配）回答："93.184.216.34"，然后浏览器才开始真正连接。

注意关键点：DNS 查询发生在连接建立之前，而且是明文走 UDP 53 端口的居多。

泄露是怎么发生的

假设你挂了代理，浏览器访问 www.example.com：

1. 理想流程：DNS 查询也通过代理发出，网站和 DNS 都只看到代理的 IP
2. 实际常见情况：系统仍然把 DNS 查询发给了本地运营商的 DNS

这时运营商（以及链路上任何能监听 53 端口流量的设备）虽然看不到你访问的内容，但能看到你解析了哪些域名——"他访问了 example.com"这件事本身，就是隐私。

典型触发场景：

• 代理客户端只接管了 TCP 流量，没接管 UDP 53
• 系统设置的静态 DNS 没有被代理覆盖
• 浏览器开了"安全 DNS"（DoH），自己找了一个上游
• 操作系统 IPv6 的 DNS 走了不同通道

怎么检测

原理很简单：让浏览器去解析一个随机生成的、全世界只有这一次检测才会用到的域名，同时记录这个解析请求来自哪个 IP。

• 如果解析请求的出口 = 你 HTTP 流量的出口（都是代理 IP）→ 正常
• 如果解析请求来自你的运营商 → DNS 泄露

这正是 IPchase 首页 六维检测里"DNS 出口"一项做的事：页面会生成一个随机子域，你的设备去解析它，我们记录解析来源，再和 HTTP 出口对比。全程无需安装任何东西。

怎么防范

方法一：在代理客户端里开启 DNS 接管

主流客户端（Clash、sing-box、Surge 等）都有"DNS 模块"或"TUN 模式"。开启后系统所有 53 端口请求都会被客户端截获、走代理解析。这是最彻底的方案。

方法二：加密 DNS（DoH/DoT）

把 DNS 查询换成 HTTPS（DoH）或 TLS（DoT）加密传输，运营商至少看不到你查了什么域名。

但注意：这不是完美替代。加密 DNS 解决"被看到"，不解决"DNS 出口和代理出口不一致"——某些检测场景下两者 IP 不同仍会被判定为泄露特征。

方法三：用代理时顺手自测一次

挂上代理后到 IPchase 跑一次检测，看"DNS 出口"和"HTTP 出口"是否一致。几十秒的事，比出事后排查省力得多。

常见误区

• "我用的是 DoH，所以不会泄露"——DoH 只加密，出口是否和代理一致是另一回事
• "DNS 泄露会暴露我的浏览内容"——不会，只暴露域名，但这已经很敏感
• "只有坏人需要关心这个"——不，它是所有代理用户的基础隐私卫生

IPv6 是漏网之鱼

相当一部分"我明明全按教程配了"的泄露，根源在 IPv6：代理客户端只接管了 IPv4 的 DNS，而系统对 IPv6 网络另有一套 DNS 配置（RA 下发的 DNS 服务器），查询直接从 v6 路径漏了出去。

自查方法：检测时留意结果里的出口是 v4 还是 v6 地址，如果你的代理只提供了 v4 出口，而检测显示某条查询走了 v6 出口——泄露源找到了。处置办法是在代理客户端开启 IPv6 接管，或者在系统层面临时禁用 IPv6（代价是放弃 v6 的直连加速）。

修复之后怎么验证

"配置过了"和"配置对了"是两回事，验证动作不能省：

1. 挂上代理，到 IPchase 首页 跑一次完整检测，确认 DNS 出口 = HTTP 出口
2. 换一个代理节点再跑一次——有些客户端只在特定分流规则下接管 DNS
3. 关掉代理再跑一次，确认检测工具能正确区分"直连状态"和"代理状态"，排除检测误报
4. 隔几天复查一次：系统更新、客户端升级都可能重置网络配置

把第 1 步养成挂代理后的固定动作，DNS 泄露这类问题基本可以做到当场发现。

小结

DNS 泄露 = 域名解析请求绕过了代理，让运营商看到了你的访问轨迹。检测靠"随机域名 + 解析来源对比"，防范靠代理客户端的 DNS 接管。

配套阅读：WebRTC 泄露——另一个常被忽略的真实 IP 暴露通道。