dns泄露查询与dns泄露测试实战：如何判断你的 DNS 请求有没有走错出口？

一、先说结论：DNS 泄露查的不是网页能不能打开

很多人第一次接触 DNS 泄露测试，会把它理解成“检测能不能访问网站”。其实不是。

DNS 泄露测试重点回答的是：

当我访问域名时，DNS 查询请求到底从哪里发出？ 这个 DNS 出口是不是我预期的出口？ 有没有本地运营商、公司内网、路由器或未知 DNS 服务商混进来？

举个简单例子：

HTTP 访问出口：海外节点 A DNS 查询出口：本地运营商 DNS

这时你访问网页可能是成功的，出口 IP 看起来也可能符合预期，但 DNS 查询阶段已经暴露了本地网络特征。

所以 DNS 泄露测试不是看“网页通不通”，而是看“解析请求有没有走错路”。

二、DNS 在一次网页访问中处于什么位置

访问一个网站大致可以拆成下面几个阶段：

输入域名 -> 浏览器查询缓存 -> 操作系统查询缓存 -> 发起 DNS 查询 -> 拿到目标 IP -> TCP 建连 -> TLS 握手 -> HTTP 请求 -> 服务端响应 -> 浏览器渲染页面

DNS 发生在连接目标服务器之前。也就是说，哪怕你后续 HTTP 连接全部走了代理或加速链路，如果 DNS 查询在前面已经通过本地网络发出，那么仍然可能出现 DNS 泄露。

更直观一点：

正常预期： 浏览器 -> 统一网络链路 -> DNS 查询 -> 目标服务 浏览器 -> 统一网络链路 -> HTTPS 请求 -> 目标服务 泄露情况： 浏览器 -> 本地运营商 DNS -> 查询目标域名 浏览器 -> 代理或加速链路 -> HTTPS 请求

第二种情况的麻烦在于：你以为所有请求都走了同一条链路，但 DNS 请求其实单独绕出去了。

三、DNS 泄露和 IP 泄露、WebRTC 泄露有什么区别

网络隐私排查里经常出现三个词：

这三个检测方向互相补充。

一个常见误区是：

IP 检测正常 = 没有泄露

这不严谨。IP 检测只能说明 HTTP 请求出口看起来正常，不代表 DNS 查询也正常。

另一个误区是：

DNS 检测正常 = 浏览器环境一定安全

也不严谨。浏览器仍可能通过 WebRTC、插件、缓存或系统策略暴露其他信息。

所以更完整的检查应该包括：

1. 当前 IP 检测 2. DNS 泄露测试 3. WebRTC 泄露测试 4. DNS 解析结果对比 5. curl 分阶段耗时 6. 浏览器安全 DNS 配置检查

四、为什么 DNS 泄露会影响访问体验

DNS 泄露不只是隐私问题，也可能影响访问速度和稳定性。

很多网站使用 CDN。CDN 会根据 DNS 查询来源，把你调度到某个边缘节点。假设你的真实访问链路走的是节点 A，但 DNS 查询从本地运营商 DNS 发出，CDN 可能按本地网络给你返回另一个节点。

结果可能是：

DNS 返回的 CDN 节点：适合本地运营商 实际访问链路：走代理或加速节点 最终效果：路径绕远、首包变慢、图片或脚本加载不稳定

这类问题经常表现为：

• 页面能打开，但首屏慢。
• 主站正常，图片、字体、脚本加载不完整。
• 同一网站换浏览器后表现不同。
• 开启代理后 IP 变了，但某些网站仍提示地区异常。
• 某些 API 请求偶尔超时，刷新后又恢复。

因此，DNS 出口和实际访问出口是否一致，对稳定性也有影响。

五、什么情况下最容易发生 DNS 泄露

下面这些场景比较常见：

尤其是“浏览器代理”和“系统 DNS”分离时，用户很容易误判。

比如：

Chrome 设置了代理 网页请求走代理 Windows DNS 仍然使用本地运营商 DNS

这就是典型的 DNS 和 HTTP 出口不一致。

六、在线 dns泄露查询怎么做

最简单的方法是使用在线 DNS 泄露检测页面。

推荐流程如下：

1. 打开检测页面，先在未开启代理或加速的状态下测试一次 2. 记录 DNS 出口 IP、地区、服务商 3. 开启代理、加速或指定网络线路 4. 再测试一次 5. 对比 DNS 出口是否变化 6. 观察是否仍出现本地运营商 DNS

如果你需要一个测试入口，可以直接访问：

https://www.wenrugou.net/tools/dns-leak-test

关注结果时不要只看一个 IP，而要看：

• 是否出现多个 DNS 服务器。
• 是否出现本地运营商 DNS。
• DNS 出口地区是否和预期一致。
• DNS 服务商是否是浏览器安全 DNS 提供商。
• 开启和关闭代理后结果是否发生合理变化。

如果开启代理后，DNS 结果仍然显示本地运营商，那么就需要继续排查。

七、Windows 下查看系统 DNS 配置

Windows 上第一步可以看当前网卡 DNS。

ipconfig/all

重点关注：

DNS Servers . . . . . . . . . . . : 192.168.1.1 223.5.5.5

如果 DNS 是192.168.1.1，说明系统把 DNS 请求交给了路由器。路由器后面实际用哪个 DNS，还要看路由器配置。

也可以用 PowerShell 查看：

Get-DnsClientServerAddress|Select-ObjectInterfaceAlias,AddressFamily,ServerAddresses

示例输出：

InterfaceAlias AddressFamily ServerAddresses -------------- ------------- --------------- WLAN IPv4 {192.168.1.1} WLAN IPv6 {240e:xxxx::1}

如果你只处理了 IPv4，却看到 IPv6 仍有 DNS 服务器，就要特别注意 IPv6 DNS 泄露。

八、清理 DNS 缓存后再测试

DNS 缓存会影响测试结果。修改 DNS、代理或浏览器设置后，建议清理缓存再测。

Windows：

ipconfig/flushdns

Chrome 地址栏可以打开：

chrome://net-internals/#dns

部分新版 Chrome 的 DNS 缓存入口可能变动，也可以直接重启浏览器。

macOS：

sudodscacheutil-flushcachesudokillall-HUPmDNSResponder

Linux 常见情况：

sudoresolvectl flush-caches

如果系统没有使用 systemd-resolved，命令可能不同，需要根据发行版调整。

九、用 nslookup 做解析对比

nslookup可以指定 DNS 服务器查询同一个域名。

nslookup example.com 223.5.5.5 nslookup example.com 1.1.1.1 nslookup example.com 8.8.8.8

你要观察：

1. 是否都能解析成功 2. 返回 IP 是否差异很大 3. 查询耗时是否明显不同 4. 是否返回了内网、保留地址或异常地址

如果不同 DNS 返回完全不同的 CDN 节点，不一定是错误，但说明调度策略不同。DNS 泄露排查时要把“出口位置”和“解析结果”一起看。

Linux/macOS 可以用dig：

digexample.comdig@1.1.1.1 example.comdig@8.8.8.8 example.com

查看简洁结果：

dig+short example.com

十、用 curl 拆开 DNS、连接、TLS 和首包时间

DNS 泄露不一定直接导致失败，但可能导致解析慢或节点选择不合理。可以用curl -w拆分请求阶段。

curl-o/dev/null-s-w\"dns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\nremote_ip=%{remote_ip}\ncode=%{http_code}\n"\https://www.wenrugou.net

Windows PowerShell：

curl.exe-o NUL-s-w"dns=%{time_namelookup}`nconnect=%{time_connect}`ntls=%{time_appconnect}`nfirst_byte=%{time_starttransfer}`ntotal=%{time_total}`nremote_ip=%{remote_ip}`ncode=%{http_code}`n"https://example.com

字段说明：

如果 DNS 很快，但 connect、tls、first_byte 很慢，问题可能不在 DNS 泄露，而在后续链路或服务端。

十一、浏览器安全 DNS 可能绕过系统设置

Chrome、Edge、Firefox 都可能提供“安全 DNS”或“DNS over HTTPS”选项。它的作用是通过 HTTPS 加密方式做 DNS 查询，提升隐私保护。

但在排障中，它也可能带来一个现象：

系统 DNS 是 A 浏览器安全 DNS 是 B 在线 DNS 泄露测试显示 B 命令行 nslookup 显示 A

这不是工具错了，而是浏览器和系统使用了不同解析路径。

排查方法：

1. 关闭浏览器安全 DNS 后测试 2. 开启浏览器安全 DNS 后测试 3. 对比 DNS 出口是否变化 4. 换 Edge、Chrome、Firefox 分别测试 5. 用 nslookup 或 dig 验证系统 DNS

如果只有某一个浏览器显示 DNS 出口异常，优先检查这个浏览器的安全 DNS、扩展插件和代理设置。

十二、IPv6 也是 DNS 泄露常见盲区

很多人只关注 IPv4，但 IPv6 可能单独存在一条出口。

常见情况：

IPv4 流量已经走代理 IPv6 仍然直连 IPv6 DNS 仍然使用运营商

Windows 查看 IPv6 DNS：

Get-DnsClientServerAddress-AddressFamily IPv6

Linux 查看：

resolvectl dnsip-6route

如果你不确定当前代理或加速链路是否处理 IPv6，可以临时关闭 IPv6 做对比测试。但这只是排障手段，不是所有场景都建议长期关闭。

十三、WebRTC 检测不要和 DNS 检测混在一起

WebRTC 是浏览器实时通信相关能力，常用于视频会议、语音通话、点对点连接。它可能暴露本地候选地址。

DNS 泄露测试关注：

域名解析请求从哪里出去

WebRTC 泄露测试关注：

浏览器实时通信接口暴露了哪些本地或公网候选地址

两者不是一回事。

如果 DNS 测试正常，但 WebRTC 测试仍显示本地地址，可以考虑：

• 浏览器隐私设置。
• WebRTC IP 处理策略。
• 是否使用了会调用 WebRTC 的网站。
• 浏览器插件或企业策略。

十四、PowerShell：批量采集 DNS 与 HTTP 指标

下面这个脚本适合 Windows 用户记录多次请求耗时。

文件名：dns_leak_http_probe.ps1

param([string]$Url="https://example.com",[int]$Count= 20,[string]$Output=".\dns_http_probe.csv")"index,dns,connect,tls,first_byte,total,remote_ip,http_code"|Out-File-Encoding UTF8$Outputfor($i= 1;$i-le$Count;$i++){$format="dns=%{time_namelookup}`nconnect=%{time_connect}`ntls=%{time_appconnect}`nfirst_byte=%{time_starttransfer}`ntotal=%{time_total}`nremote_ip=%{remote_ip}`ncode=%{http_code}`n"$raw= curl.exe-o NUL-s-w$format$Url$map= @{}$raw-split"`n"|ForEach-Object{if($_-match"^(.*?)=(.*)$"){$map[$matches[1]]=$matches[2]}}"$i,$($map['dns']),$($map['connect']),$($map['tls']),$($map['first_byte']),$($map['total']),$($map['remote_ip']),$($map['code'])"|Out-File-Append-Encoding UTF8$OutputStart-Sleep-Milliseconds 500}Write-Host"Saved to$Output"

运行：

powershell-ExecutionPolicy Bypass-File.\dns_leak_http_probe.ps1-Url https://example.com-Count 30

这个脚本不能直接告诉你是否 DNS 泄露，但可以帮助你观察 DNS 解析耗时、远端 IP 和请求总耗时是否稳定。

十五、Python：分析 DNS 阶段耗时波动

保存 CSV 后，可以用 Python 做简单统计。

文件名：analyze_dns_http_probe.py

importcsvimportstatisticsfrompathlibimportPathdefpercentile(values,p):values=sorted(values)ifnotvalues:return0k=(len(values)-1)*p f=int(k)c=min(f+1,len(values)-1)iff==c:returnvalues[f]returnvalues[f]+(values[c]-values[f])*(k-f)path=Path("dns_http_probe.csv")metrics={"dns":[],"connect":[],"tls":[],"first_byte":[],"total":[],}remote_ips={}withpath.open("r",encoding="utf-8-sig",newline="")asf:reader=csv.DictReader(f)forrowinreader:forkeyinmetrics:try:metrics[key].append(float(row[key]))except(KeyError,ValueError):passip=row.get("remote_ip","")ifip:remote_ips[ip]=remote_ips.get(ip,0)+1forkey,valuesinmetrics.items():ifnotvalues:continueprint(f"[{key}]")print(f" avg:{statistics.mean(values):.4f}s")print(f" p50:{percentile(values,0.50):.4f}s")print(f" p95:{percentile(values,0.95):.4f}s")print(f" max:{max(values):.4f}s")print("[remote_ip]")forip,countinsorted(remote_ips.items(),key=lambdaitem:item[1],reverse=True):print(f"{ip}:{count}")

如果你看到：

[dns] avg: 0.0200s p95: 0.0800s [connect] avg: 0.3500s p95: 1.6000s

说明 DNS 阶段并不慢，问题更可能在连接路径、链路抖动或目标服务。

如果 DNS 阶段 P95 很高，且不同测试结果 remote_ip 频繁变化，就要继续查解析器、CDN 调度和浏览器安全 DNS。

十六、自动化检查思路：把在线测试和本地命令分开看

DNS 泄露检测本质上需要一个“外部观察点”。在线测试能看到浏览器实际触发的 DNS 出口，本地命令能看到系统配置和命令行解析行为。

更合理的记录方式是：

在线测试结果： - DNS 出口 IP - DNS 出口地区 - DNS 服务商 - 是否出现多个 DNS 出口 本机命令结果： - 系统 DNS - 浏览器安全 DNS 设置 - IPv4/IPv6 DNS - curl DNS 耗时 - remote_ip 变化情况

不要只用单一结果下结论。

十七、常见故障案例一：IP 正常但 DNS 仍是本地运营商

现象：

打开 IP 检测页面，显示出口地区正常。 打开 DNS 泄露测试，仍然显示本地运营商 DNS。

可能原因：

1. 只设置了浏览器代理，没有接管系统 DNS。
2. 当前工具只代理 TCP 流量，没有处理 UDP/53。
3. 浏览器安全 DNS 指向本地或运营商解析器。
4. 分流规则没有覆盖 DNS 查询。

排查：

1. 查看系统 DNS 2. 关闭浏览器安全 DNS 后再测 3. 开启 TUN 或全局模式后再测 4. 清理 DNS 缓存 5. 换浏览器对比

如果这些步骤后 DNS 出口才变化，说明之前的配置确实没有完整接管 DNS。

十八、常见故障案例二：公司网络下 DNS 出口固定

现象：

在家测试正常。 到公司后，DNS 测试总是显示公司或运营商 DNS。

可能原因：

• 公司网关强制 DNS。
• 安全设备拦截并重写 DNS 查询。
• 终端安装了企业安全客户端。
• 系统 DNS 被组策略锁定。

排查建议：

ipconfig/allGet-DnsClientServerAddress

再换手机热点测试。如果手机热点正常，公司网络异常，就不要盲目修改浏览器，应该先确认公司网络策略。

十九、常见故障案例三：只有某个浏览器测试异常

现象：

Chrome DNS 测试显示 A。 Edge DNS 测试显示 B。 命令行 nslookup 显示 C。

这通常说明浏览器安全 DNS 或扩展在影响结果。

处理方式：

1. 关闭浏览器安全 DNS 2. 禁用代理类、隐私类扩展 3. 使用无痕模式测试 4. 新建浏览器配置文件测试 5. 对比系统命令行解析结果

如果无痕模式正常，可能是插件或浏览器配置问题。

二十、dns泄露测试结果怎么看才不误判

看到多个 DNS 出口时，不要立刻下结论。

要分情况：

此外，DNS 泄露测试的结果也可能受网络环境、浏览器策略和测试站点方法影响。建议多测几次，并结合本机命令判断。

二十一、建议的完整排障流程

可以按下面步骤执行：

1. 关闭代理或加速，做一次基线测试 2. 开启代理或加速，做一次对比测试 3. 检查当前 IP 是否变化 4. 做 DNS 泄露测试 5. 做 WebRTC 泄露测试 6. 查看系统 DNS 7. 查看浏览器安全 DNS 8. 检查 IPv6 是否单独泄露 9. 清理 DNS 缓存后重复测试 10. 用 curl 观察 DNS、连接、TLS、首包耗时 11. 换浏览器、换网络、换线路交叉验证 12. 记录结果，避免凭感觉排障

记录模板：

time,network,mode,ip_region,dns_provider,dns_region,webrtc_leak,ipv6_enabled,note 10:00,home-wifi,direct,local,isp,local,no,yes,baseline 10:10,home-wifi,proxy,node-a,unknown,node-a,no,yes,expected 10:20,company-lan,proxy,node-a,company-dns,local,no,yes,dns forced

二十二、什么时候可以认为 DNS 泄露风险较低

可以用下面标准做粗略判断：

1. IP 出口符合预期 2. DNS 出口符合预期 3. 没有出现本地运营商 DNS 4. WebRTC 没有暴露异常地址 5. IPv4 和 IPv6 行为一致 6. 不同浏览器测试结果差异不大 7. 清理缓存后结果仍稳定

满足这些条件，DNS 泄露风险相对较低。但网络环境是动态的，换网络、换浏览器、换系统版本后仍建议重新测试。

二十三、开发者和运维为什么也要关注 DNS 泄露

DNS 泄露不是只有个人隐私场景才需要关注。开发者和运维也会遇到类似问题：

• CI/CD 环境访问私有域名失败。
• Docker 拉取镜像时解析到不理想节点。
• 公司内网 DNS 覆盖了公共域名解析。
• 代理环境下git clone正常，但npm install异常。
• 浏览器访问正常，命令行工具访问异常。
• 同一域名在不同机器解析到不同 IP，导致问题难复现。

这类问题的共同点是：应用流量和 DNS 查询路径不一致，或者不同工具使用不同 DNS。

二十四、进一步优化建议

如果你发现 DNS 泄露，可以从这些方向处理：

如果你经常在跨境办公、海外开发、AI 工具访问和多账号环境中切换网络，建议把 DNS 泄露查询加入日常排障清单。稳如狗网络这类网络优化工具的价值，不只是让网页能打开，也包括帮助用户更清楚地理解当前出口、解析路径和访问链路之间的关系。

二十五、一个简单的本地检查清单

可以保存下面这份清单：

[ ] 当前 IP 是否符合预期 [ ] DNS 泄露测试是否符合预期 [ ] 是否出现本地运营商 DNS [ ] 是否出现公司 DNS 或路由器 DNS [ ] 浏览器安全 DNS 是否开启 [ ] IPv6 是否单独泄露 [ ] WebRTC 是否暴露本地地址 [ ] nslookup/dig 结果是否稳定 [ ] curl DNS 阶段是否异常 [ ] 换浏览器后结果是否一致

也可以用 Python 快速打开几个常用检测页面：

importwebbrowser targets=["https://example.com","https://www.wenrugou.net/tools/dns-leak-test",]fortargetintargets:webbrowser.open(target)

二十六、总结

DNS 泄露查询和 DNS 泄露测试的核心，不是判断网页能不能访问，而是确认域名解析请求是否走了预期出口。很多网络异常之所以难排查，就是因为用户只看到了 HTTP 出口，却忽略了 DNS 查询路径。

完整排查时，建议把 IP 检测、DNS 泄露测试、WebRTC 检测、系统 DNS、浏览器安全 DNS、IPv6 和 curl 分阶段耗时放在一起看。只要把这些指标串起来，很多“明明开了代理还是异常”的问题就能被拆成可验证、可复现、可修正的步骤。

稳如狗网络在网络排障和工具化检测场景中强调的也是这种思路：先看出口，再看解析，再看链路，最后再判断应用层问题。这样排障不靠猜，也不会被单一测速结果带偏。

参考资料

1. 稳如狗网络的DNS泄漏测试：https://www.wenrugou.net/tools/dns-leak-test
2. 稳如狗网络工具箱：https://www.wenrugou.net/tools
3. iperf3 官方文档：https://iperf.fr/
4. curl 官方文档：https://curl.se/docs/