502云最新网址

DNS泄露怎么检查和修复？按设备与代理环境逐步排查

更新于 2026-11-01 · 502jsq.online

简答：如果开启代理后检测结果仍出现本地运营商或家庭路由器的DNS，先不要反复更换解析地址：关闭代理建立一次基线，再开启代理复测，随后分别检查系统DNS、浏览器DoH、IPv6、TUN或客户端DNS接管。修复后清理缓存、重连网络，并用相同条件再次检测。

定义：DNS泄露是指设备在使用代理或加密连接时，域名解析请求仍通过未预期的本地、运营商、路由器或其他解析器发出。

先做这一步：用基线对照判断是否真的泄露

本站是独立的使用指南站，不是任何客户端或网络服务的官方网站。判断DNS泄露，重点不是检测页面显示了哪个城市，而是比较“关闭代理”和“开启代理”时实际参与解析的服务器是否发生了符合预期的变化。

检测结果与处理方向速查
检测现象通常说明下一步
关闭和开启代理都显示同一组家庭宽带或运营商解析器代理可能只接管了部分流量，DNS仍由系统或路由器处理检查客户端的DNS接管、TUN、分流和浏览器独立DNS设置
开启代理后显示代理侧或预期的解析器从该检测结果看，DNS路径已发生变化仍需检查IPv6、浏览器DoH和其他应用是否绕过
显示多个地区或多个解析器可能是Anycast、多个网络接口、IPv4与IPv6并行或不同应用分别解析分别关闭IPv6、关闭浏览器独立DNS并重测，记录变化
只显示公共DNS，不显示本地运营商不等于所有流量都经过代理，也不等于不存在其他泄露继续检查真实出口IP、WebRTC和客户端分流；DNS检测只反映DNS路径
  1. 关闭代理客户端、系统VPN和浏览器独立DNS，连接当前网络。
  2. 记录一次检测结果，至少保存解析器名称、所属组织或地区、IPv4/IPv6是否都有结果。
  3. 只开启一种代理方式，再访问同一个检测页面。
  4. 两次使用同一浏览器、同一网络和相近时间，避免把网络切换造成的差异误判为修复。

如果需要确认某台设备是否使用特定公共解析器，可使用其官方帮助页进行连通性验证。例如，Cloudflare文档建议访问 1.1.1.1/help 查看设备是否通过其解析器工作；这只能证明与该解析器的连接情况，不能单独证明不存在DNS泄露。

先分清：DNS泄露不等于DNS劫持、污染或IP泄露

几个容易混淆的问题
问题核心表现检查重点
DNS泄露查询请求走了不希望使用的解析器比较代理前后解析器及IPv4、IPv6路径
DNS劫持解析请求或响应被改写，常见表现是跳转到错误页面或返回异常地址用不同解析器查询同一域名并比较结果
DNS污染部分域名解析失败、返回不一致或在特定网络下异常对照多个网络和多个解析器，不要只看单次结果
真实IP泄露网页、应用或连接仍暴露设备当前出口地址单独检查出口IP和应用连接路径
WebRTC泄露浏览器接口可能暴露本地或网络地址信息使用专门的WebRTC检查，不要用DNS检测结果代替

DNS解析器能把域名转换成IP地址；传统DNS请求可能以明文传输，而DoH和DoT分别通过HTTPS或TLS加密DNS请求。加密传输可以减少网络路径上的直接窥视，但它不会自动保证浏览器、系统和代理客户端使用的是同一条解析路径。相关协议区别可参考 Cloudflare DNS加密说明。

Windows：恢复可控状态，再检查IPv4、IPv6和缓存

  1. 打开“设置—网络和Internet”，进入当前Wi‑Fi或以太网连接的属性，查看DNS服务器分配方式。排查时优先记录原设置，不要一开始就随意填入多个公共DNS。
  2. 打开命令提示符，执行 ipconfig /all，记录当前网卡的DNS服务器、默认网关和IPv6相关信息。
  3. 清理本机DNS缓存：ipconfig /flushdns。Microsoft将该命令列为Windows DNS客户端排查步骤之一，说明见 Microsoft DNS故障排查文档。
  4. 先在关闭代理时检测，再只打开一种代理模式检测。若IPv4结果符合预期、IPv6结果仍显示本地网络或运营商解析器，优先在客户端或网卡层检查IPv6处理，而不是只更换IPv4 DNS。
  5. 若代理软件提供“DNS接管”“远程DNS”“TUN”或“防止DNS泄露”等选项，逐项只改一个设置，然后断开并重新连接测试。

异常分流：系统代理开启但只有浏览器能走代理，通常要检查应用是否支持系统代理；TUN已开启但DNS仍走本地路径，则检查虚拟网卡权限、客户端DNS模式和分流规则。无法确认设置作用时，先恢复原配置，再按单变量方式复测。

macOS、Linux与浏览器：不要只看系统设置

macOS

macOS可在“苹果菜单—系统设置—网络—当前网络服务—详细信息—DNS”查看或调整DNS服务器。Apple的操作路径见 Apple更改Mac DNS设置说明。修改前记录原有服务器，完成后断开并重新连接网络，再进行基线对照。

Linux

如果系统使用systemd-resolved，可先执行 resolvectl status 查看全局及各网卡DNS，使用 resolvectl flush-caches 清理缓存。官方文档说明，resolvectl status可显示当前生效的DNS设置，flush-caches可清理该服务维护的缓存，具体命令以当前发行版帮助页为准，参考 systemd resolvectl文档。

不要直接覆盖/etc/resolv.conf后就认为问题解决：该文件可能是符号链接，也可能由网络管理服务自动生成。先确认实际管理者，再修改；如果修改后断网，恢复备份并重启网络服务。

浏览器DoH

浏览器可能绕过系统DNS，单独通过DoH解析。Firefox可在“设置—隐私与安全—DNS over HTTPS”查看保护级别；Mozilla说明，默认保护模式可能根据网络、VPN或企业策略回退到系统解析器，而最大保护模式会持续使用安全DNS，详见 Firefox DNS over HTTPS说明。

排查时建议先暂时关闭浏览器独立DNS，使用系统或代理客户端统一接管完成一次对照；如果关闭后结果变化，说明浏览器DNS路径与系统或客户端不一致。确认代理环境允许后，再决定是否重新启用DoH。

Android与iPhone：检查Private DNS、VPN配置和描述文件

Android

以Pixel系统为例，可进入“设置—网络和Internet—Private DNS”，选择“关闭”“自动”或“Private DNS提供商主机名”。Google说明，Private DNS只保护DNS问题与回答，不能保护其他网络流量，操作路径见 Pixel网络与Private DNS设置。

  1. 关闭代理或VPN，记录Private DNS当前状态。
  2. 开启代理客户端后，检查Private DNS是否与客户端的DNS接管产生冲突。
  3. 若客户端要求TUN或VPN权限，确认系统顶部出现对应连接标识，再进行检测。
  4. 切换“自动”和“关闭”各测试一次，只保留能够解释检测结果且不影响正常解析的配置。

iPhone与iPad

iOS的DNS路径通常受到Wi‑Fi网络设置、VPN配置、DNS配置描述文件或客户端权限影响。Apple的设备管理文档显示，受管理设备可以通过DNS设置将查询导向DoH或DoT，并可配置按需规则，参考 Apple设备DNS设置说明。普通用户如果看不到独立DNS入口，应检查当前Wi‑Fi详情、VPN与设备管理中的DNS或VPN配置，而不是随意安装未知描述文件。

代理客户端与路由器：为什么“系统代理”不一定能防DNS泄露

系统代理通常只影响遵循系统代理设置的应用；某些应用可能直接发起DNS请求，浏览器也可能启用独立DoH。TUN模式通常负责接管更广泛的IP流量，但是否包含DNS、IPv6和局域网流量，取决于客户端、内核、权限与规则配置，不能仅凭开关名称判断。

客户端排查顺序
顺序检查项可观察结果
1确认客户端只有一个实例或一个VPN连接在运行避免多个虚拟网卡或多个DNS接管程序互相覆盖
2查看DNS模式、远程DNS、分流和IPv6选项明确哪些查询走代理、哪些查询直连
3分别测试系统浏览器和目标应用判断是全局路径问题，还是单个应用绕过
4关闭代理后恢复自动DNS或原配置能够回滚，避免改动持续影响日常网络

路由器场景还要检查WAN口DNS、DHCP下发的DNS、IPv6 RA或DHCPv6下发的DNS，以及是否存在家长控制或自定义解析。家庭网络中多台设备共用路由器时，先用一台设备建立对照，不要同时改路由器和终端，否则难以判断是哪一层生效。

修复后怎么复测：满足三个条件才算完成

  1. 同条件：使用同一网络、同一设备、同一浏览器和同一代理模式。
  2. 看变化：比较代理关闭与开启时的解析器、IPv4、IPv6和应用表现，不把地区变化单独当作泄露证据。
  3. 做回滚：关闭代理后仍能正常上网；如果不能，恢复系统DNS、浏览器DoH、IPv6和客户端设置到修改前状态。

如果结果仍然不一致，按“浏览器—系统—客户端—虚拟网卡—路由器—IPv6”顺序逐层关闭或恢复，每次只改一个变量。DNS检测只能说明DNS请求路径，不能替代真实出口IP、WebRTC或应用连接测试。

常见问题

检测结果显示公共DNS，是不是就没有DNS泄露？

不是。公共DNS只说明检测页面观察到某个公共解析器；仍可能存在浏览器DoH、IPv6、其他应用或分流规则使用不同解析路径。至少完成代理关闭与开启的对照，并分别检查IPv4和IPv6。

DNS泄露检测显示多个解析器，是否一定是配置错误？

不一定。多个网卡、IPv4与IPv6并行、Anycast节点或不同应用的解析方式都可能造成多个结果。先关闭浏览器独立DNS和IPv6做对照，再观察结果是否收敛。

改成公共DNS能不能直接修复DNS泄露？

通常不能保证。更换解析器只改变“使用哪个DNS”，不一定改变“DNS请求经过哪条网络路径”。代理场景还要检查客户端DNS接管、TUN、分流和浏览器DoH。

开启浏览器DoH后，系统DNS还会泄露吗？

对该浏览器的查询路径可能发生变化，但其他应用、系统服务或IPv6流量仍可能使用系统DNS。DoH是浏览器或系统的一条解析方式，不等同于全设备流量都经过代理。

修复后网页能打开，是否说明DNS问题已经解决？

不能。网页能打开只说明当前访问成功，无法证明DNS路径符合预期。应重新执行相同条件的检测，并记录解析器、IPv4和IPv6结果；单次成功也不代表长期稳定。

DNS泄露和真实IP泄露有什么区别？

DNS泄露关注域名查询由谁处理，真实IP泄露关注网页或应用看到的出口地址。两者应分别测试，修复DNS不会自动改变真实出口IP，也不会自动解决WebRTC问题。

常见问题

DNS泄露检测显示公共DNS，是不是就没有DNS泄露？

不是。公共DNS只代表检测页面观察到该解析器，仍需检查浏览器DoH、IPv6、其他应用和代理分流。

改成公共DNS能不能直接修复DNS泄露？

不一定。更换DNS地址不等于改变DNS请求路径，代理环境还要检查客户端DNS接管、TUN和浏览器独立DNS。

检测显示多个解析器，是否一定是配置错误？

不一定，多个网卡、IPv4与IPv6并行、Anycast或不同应用的解析方式都可能产生多个结果。

DNS泄露和真实IP泄露有什么区别？

DNS泄露关注域名查询由谁处理，真实IP泄露关注网站或应用看到的出口地址，两者需要分别测试。

相关阅读

参考资料

  1. Microsoft Learn：Troubleshooting DNS issues
  2. Apple Support：Change DNS settings on Mac
  3. Mozilla Support：Firefox DNS over HTTPS
  4. freedesktop.org：resolvectl与systemd-resolved（freedesktop.org）
  5. Google Pixel Help：Private DNS与网络设置
  6. Cloudflare Developers：DNS加密方式
  7. Cloudflare Developers：验证DNS解析器连接
  8. support.apple.com