DNS 泄露指：你已经启用 VPN 或以为查询会走受信路径，但域名解析仍经由本地网络、运营商解析器、路由器或浏览器内置解析通道完成，从而向非预期的观察者暴露你问了哪些域名。这与网页内容是否 HTTPS 无关——查询阶段的意图泄漏独立存在。
DNS 在连接链条中的位置
用户输入 example.com 后，系统或应用向递归解析器发起查询，获得 A/AAAA 记录，再向对应 IP 建立 TCP/TLS 连接。递归解析器天然能看到查询名；若查询未加密，同一局域网或上游网络也可能观察到。基础机制见 DNS 服务器如何工作。
VPN 场景为何高发
隧道通常只保证进入隧道的 IP 包按新路径转发；DNS 是另一通道。常见成因包括：客户端未推送隧道 DNS；操作系统仍优先使用 DHCP 下发的解析器；浏览器单独启用 DoH 指向与 VPN 无关的服务商；分流规则让部分域名故意走直连，但你未意识到该域名落在直连列表。意外泄露与预期分流的区别在于行为是否符合你写下的策略，而不是「有没有本地解析」这一事实本身。
Split tunnel 与 leak 的辨析
企业 VPN 常让内网域名走本地解析、互联网域名走隧道——这是设计如此。家庭用户若希望「全部上网隐私一致」，却仅加密 HTTP 流量而 DNS 仍指向运营商，就属于配置错误。核对时应同时看 IP 出口、DNS 出口与分流表，而不是只看客户端显示「已连接」。相关：VPN 原理。
DoT 与 DoH 能缓解什么
DNS over TLS（RFC 7858）与 DNS over HTTPS（RFC 8484）在传输层加密查询，降低路径窃听与篡改，并让客户端固定指向指定解析策略。但它们不自动把查询藏进 VPN 隧道：若 DoH 在浏览器层指向 Cloudflare，而网页流量走 VPN 出口，可能出现「IP 在德国、DNS 在美国」的刻意或无意组合。解析服务商仍能看到完整查询列表。Mozilla 文档对 Firefox 中 DoH 的行为与策略有说明。
如何检测
- 连接 VPN 前后，使用你信任的检测页或自建脚本，对比显示的 DNS 与 IP 是否符合策略。
- 更换客户端版本、系统升级或安装新浏览器后复测；泄露状态不是一次通过就永久有效。
- 检查 IPv6：若仅 IPv4 入隧而 IPv6 仍直连，会形成隧道路径旁路（直连）。
- 确认厂商文档中的「仅隧道 DNS」「阻止 LAN DNS」等选项是否按预期开启。
缓解思路
- 在 VPN 配置中指定隧道内 DNS，并验证查询出口与隧道一致。
- 在路由器或系统层统一加密 DNS，减少应用各自解析。
- 理解分流清单：预期直连的域名不应被误报为泄露。
- 高敏感场景叠加 HTTPS，并限制在不可信网络上进行账户关键操作。
WebRTC 与系统解析缓存
部分浏览器在 WebRTC 场景下可能泄露本地接口或 STUN 探测结果，与 DNS 泄露并列是另一类「隧道已开但仍有侧信道」的问题。系统级 DNS 缓存与 hosts 文件也会让检测页结果与即时抓包不一致——改配置后重启解析服务或清缓存再测更可靠。分流清单若以域名后缀匹配，要确认通配规则没有把本应入隧的流量误送进直连解析器。
仍无法指望 DNS 加密单独完成的事
DoH/DoT 不阻止解析服务方看到查询内容；不替代 HTTPS 对页面正文的保护；也不阻止已登录账户在服务端记录行为。流量模式、SNI（视协议版本与部署而定）与 IP 地址仍是独立信号。
运营商与本地网关能看见什么
未入隧的明文 DNS 查询会经过本地路由器与运营商递归，常被用于 parental control、恶意域名拦截或合规审计。加密 DNS 把「谁能看到查询名」转移到你所选的解析商，而不是让查询从地球上消失。更换 VPN 国家后若忘记同步 DoH 配置，检测页仍可能显示与出口国家不一致的解析位置——这正是许多用户误以为「VPN 坏了」的实际原因。
排障顺序建议：先确认 VPN 路由与杀开关，再核对加密 DNS 策略，最后用 HTTPS 站点验证内容层是否独立正常。