- DNS 是访问一切网站的第一步：浏览器发出查询 -> 递归解析器逐级问询 -> 目标权威域名服务器能直接记下「发起查询的递归解析器 IP」。
- 代理环境下发生 DNS 泄漏的四大主因：代理仅接管 IP 连接未接管域名解析、分流规则「先解析再路由」导致本地抢跑、浏览器 DoH/系统 DNS 绕行，以及 IPv6 DNS 逃逸。
- 权威检测原理是访问一次性随机生成的全新子域名（零缓存命中），通过权威端捕获的解析器 ASN 与国家来对比代理出口是否一致。
- 根治策略：开启代理端 TUN + Fake-IP / DNS 劫持，SOCKS5 务必选择远程解析（socks5h），关闭未受控的 IPv6，并确保浏览器安全 DNS 与代理线路对齐。
1. DNS 查询三步链路：谁能看到你的真实网络身份？
在浏览器向任何网站建立 TCP 或 QUIC 连接之前，设备必须先完成「域名到 IP 地址」的翻译，这就是 DNS（Domain Name System）的核心职责。正常情况下，这笔请求会沿着以下三步向上游传递：
- Step 1 · 发起本地查询:浏览器请求访问 example.com 时，默认把域名交给操作系统的 stub resolver（或浏览器内建的安全 DNS 客户端）。
- Step 2 · 递归解析器逐级追问:系统指定的递归解析器（通常是家里路由器转发的当地运营商 DNS，如电信/联通 114/运营商网关，或企业内网 DNS）负责向根服务器、TLD 与目标权威服务器逐级递归拿回 IP。
- Step 3 · 权威服务器直见「来问路的人」:目标域名的权威服务器返回最终 A/AAAA 记录的同时，日志里清清楚楚记录着「是哪一个递归解析器 IP 来问的」。
权威服务器看不到隔在递归器背后的你的内网地址，但它看到了「是谁替你来问路」——如果你挂着美国洛杉矶的代理 IP，目标站前端同时请求一个防欺诈子域名，权威 DNS 捕获到的解析请求却来自中国江苏电信的 DNS 服务器（有时还附带 EDNS Client Subnet 网段），你的实际所在地与代理身份当场穿帮。
2. 为什么已经开了代理 / VPN，DNS 却依然会泄漏？
在跨境团队与工程师排查记录中，90% 以上的 DNS 泄漏并不是因为代理工具坏了，而是以下四个底层架构误区导致的：
代理只接管了连接，没接管解析
部分浏览器代理设置（例如传统 socks5:// 模式而非 socks5h://）会先由本地操作系统用当地宽带 DNS 查出目标 IP，再仅仅把这个数字 IP 扔进代理隧道去连接。
分流规则「先用本地 DNS 解析再判路」
开启「国内直连、国外代理」的规则分流（GeoIP 判断）时，如果客户端需要先把域名解析出真实 IP 才能查表决定走哪条线，而这一步默认向系统或国内公共 DNS 发问，就构成了分流前的 DNS 泄漏。
系统网卡硬编码 DNS 或浏览器独立 DoH
在 Chrome/Edge/Firefox 中手动开启了指向某个特定服务商的 DoH（DNS over HTTPS），或 Windows 网卡固定填写了特定 DNS，可能会绕过代理客户端的本地透明劫持策略直接出网。
代理仅接管 IPv4，IPv6 DNS 直连本地
本地宽带已开启 IPv6 双栈且网关分配了运营商 IPv6 DNS，而代理节点只配置了 IPv4 路由规则时，操作系统发起的 AAAA 与 IPv6 DNS 查询会毫发无损地穿过物理宽带直连上游。
交互诊断器：DNS 递归解析链路与权威端可见性对照
PRV-02 LAB3. 权威检测原理：为什么测试工具要请求随机乱码子域名？
你可能会发现，每次运行 MyIP 或 DNS Leak 检测时，浏览器的后台会闪过一串类似 `a8f31c9e.dns-test.example` 的无意义随机子域名。这正是整个检测最巧妙的地方：
- 强制击穿所有各级缓存:如果是访问 google.com 或 cloudflare.com，浏览器缓存、系统 DNS 缓存或上游路由器早已存好结果，根本不会触发真实远端查询；只有每次实时生成的全局唯一随机子域名，才能保证 0% 缓存命中，强迫 DNS 查询请求必须一路打到检测服务掌控的权威服务器。
- 比对「解析器国家/ASN」与「HTTP 代理出口」:检测服务的权威端会记录下究竟是谁连过来问这串随机子域名，并将解析器列表回传前端展示。若解析器的 ASN 属于你本地运营商、或所在国家与当前代理出口冲突，即判定存在 DNS 泄漏。
- 如何客观解读公共 DNS（1.1.1.1 / 8.8.8.8）？:当你的解析器列表显示为 Cloudflare（AS13335）、Google Public DNS（AS15169）或上游机房自带递归器时，只要解析器在权威端实际呈现出的「落地节点国家」与你的代理出口国家一致（例如都落在美国、英国或日本），由于 Cloudflare/Google 遵循 Anycast 就近路由，这恰恰证明查询确实先穿过了代理节点再就近向全球公共 DNS 问询，通常属于安全合规状态。
4. 分场景 DNS 防泄漏修复实操清单
根据你日常使用的代理协议与工具形态，选择对应的工程闭环配置：
| 使用工具 / 模式 | 关键设置项 | 核心作用机制 | 常见失效避坑点 |
|---|---|---|---|
| TUN 虚拟网卡 + Fake-IP | 开启 TUN Mode，DNS 模式选 fake-ip 且劫持 53 端口 UDP/TCP | 应用请求域名时瞬间返回 198.18.x.x 虚地址，真实域名直传远程代理端解析 | 确保系统没有其他 VPN/杀毒 DNS 代理与 53 端口劫持打架 |
| SOCKS5 独立浏览器配置 | 勾选「使用 SOCKS v5 时通过代理进行 DNS 解析」（curl 使用 socks5h://） | 浏览器不碰系统 DNS，把完整域名字符串封装进 SOCKS5 协议交由远端代理服务器解 | 部分仅监听 HTTP CONNECT 的工具会自动发域名，但直用 socks5:// 协议号常默认本地解 |
| Rule 规则分流模式 | nameserver 配国内高可用 DNS，fallback / proxy-server-nameserver 走代理隧道查海外 | 禁止在命中境外代理规则之前先行触发本地 GeoIP 反查；非中国大陆域名交远端节点解析 | 勿开启尊重本地系统 DHCP 下发的运营商 DNS 选项 |
| 双栈 IPv6 网络环境下运行 | 禁用未代理环境的 IPv6 网卡，或购买同时接管 IPv4/IPv6 的双栈隧道规则 | 彻底切断操作系统借 IPv6 AAAA 与 240x::/2001:: DNS 服务器旁路直连的途径 | 即使关闭终端 IPv6，重启路由器/切换 Wi-Fi 后仍需关注虚拟网卡是否透传 RA |
在指纹浏览器或专用工作区 Chrome 中，若代理本身已稳定接管 DNS（通过远程解析），建议关闭浏览器内部独立直连第三方 DoH 的选项（设为「关闭」或「使用操作系统默认安全配置以便由代理接管」），防止浏览器的 HTTPS 加密查询绕行直连其它区域。
DNS 泄漏高频疑问解答 (FAQ)
DNS 检测结果里出现多个解析器 IP，但都写着 Cloudflare 或 Google 正常吗？
只要它们呈现的国家/地区与你的代理出口（例如美国代理 -> 美国地区的 Cloudflare/Google DNS 节点）完全一致，就属于正常且无本地泄漏的状态。大型分布式公共 DNS 会由代理出口机房所在城市的 Anycast 节点簇响应，多个同区 IP 是负载均衡所致；但如果出现了中国香港、新加坡、甚至你真实所在省份运营商的解析器 IP，就说明分流规则或 DoH 发生了串区与泄漏。
用了 HTTPS 加密网站（HTTPS/TLS 握手），本地运营商还能看到我在逛什么网站吗？
如果发生了 DNS 泄漏，能直接看到明文域名！因为 DNS 传统走 UDP 53 端口是明文的，而且在 TLS 握手前的第一步就已经把域名交给了当地运营商。即便是网页本身有 TLS，运营商依然知道你在什么时候解析了哪个竞争对手网站、哪个广告后台或银行站点。
Fake-IP 模式和 Redir-Host 有什么本质区别？防泄漏哪个更彻底？
在防 DNS 泄漏角度，Fake-IP 往往更彻底也更快：浏览器向系统询问域名时，本地客户端根本不去上游跑真实解析，直接立即伪造返回一个 `198.18.0.x` 保留 IP 让流量第一时间进入代理隧道，最终域名原封不动带到远端代理节点再去解析，零本地漏出、零 RTT 延迟。缺点是部分依赖查看真实外网 IP 连通性的局部工具（如某些本地 P2P 测速或内网运维端）需要单独把域名写进 Fake-IP Filter 过滤名单。
为什么我明明开了 Chrome 的「安全 DNS（DoH）」，测试还是出现了国内运营商 DNS？
多半是因为浏览器 DoH 选择的是「自动 / 使用当前服务商」而非自定义海外 DoH，或者你的企业策略/校园网阻断了默认 DoH 端点导致浏览器静默降级（Fallback）回了系统原配运营商 UDP 53；更稳妥的做法是统一在支持 TUN + 远程 DNS 的代理网关层面收口，不再让浏览器和系统各自为战。
即刻排查你的 DNS 解析器归属地与双栈泄漏风险
通过随机无缓存子域名向多路节点验证真实递归解析器 ASN，对照当前出口代理实现 100% 环境闭环。