网页能正常打开，不代表域名查询也走了预期的加密通道。要判断是否发生泄露，可以按这套加密连接DNS泄露的检测流程，从设备设置一路核对到外部可见的解析器。测试结果只能反映当前设备、网络和浏览器组合，换一个环境就应重新检查。
第一步：先确定应当通过哪条通道
记录你使用的加密连接、设备和浏览器，并明确预期：DNS 请求应由加密连接提供的解析器处理，还是由你指定的公共解析器处理。若不清楚服务商配置，可查看其客户端或帮助文档；不要只根据某个解析器的名称猜测。
记下测试时的网络类型、是否启用 IPv6，以及浏览器的“安全 DNS”设置。浏览器的 DNS over HTTPS（DoH）可能独立于系统设置发送查询；DNS over TLS（DoT）则是另一种加密解析方式。不同实现可能采用不同出口，后续核验时要考虑这一点。
第二步：检查系统和浏览器配置
系统设置能帮助定位异常，但不能单独证明没有泄露。Windows 可在网络适配器的 DNS 设置中查看服务器地址，也可用“ipconfig /all”查看各适配器信息；macOS 可在“系统设置”的网络详情中检查 DNS；Linux 桌面环境可查看当前网络连接的 DNS 配置。重点留意加密连接启用后，原网络适配器是否仍列出原来的解析器。
再检查浏览器设置中的安全 DNS或自定义 DoH 服务。若浏览器指定的解析器与系统、加密连接配置不同，网页查询可能走另一条路径。先记录设置，不急着关闭功能：测试目的是找出实际路径，而不是把所有 DNS 加密方式一概视作问题。
第三步：发起新的解析请求
打开浏览器的 DNS 泄露检测页面，运行标准测试；如果页面提供扩展测试，也可再跑一次。测试站点通常会让浏览器查询若干域名，再根据收到请求的递归解析器显示结果。确保加密连接已经建立，并尽量关闭其他浏览器标签页，减少无关请求。
为避免缓存干扰，可重新载入检测页，或在测试前清理浏览器的 DNS 缓存后再测。不同操作系统和浏览器的清理入口并不相同，不必为了测试随意删除系统文件。只测一次容易漏掉间歇性问题，建议断开并重连加密连接后重复操作。
第四步：核对解析器，而不只看地址
对照检测结果中的解析器地址、运营方或网络归属，与第一步记录的预期是否相符。解析器显示为网络接入服务商、家庭路由器上游或其他陌生网络时，应进一步调查；但单凭地理位置或名称不同，不能直接断定泄露。解析器可能使用共享设施、转发服务或 Anycast，显示信息也可能不够精确。
需要更细致核查时，可在 Wireshark 中观察测试期间的网络流量：传统 DNS 常使用 UDP 或 TCP 53 端口，DoT 常使用 TCP 853。DoH 通常借助 HTTPS 的 443 端口，单看端口无法确认请求内容，也不宜据此认定某个连接一定承载 DNS。抓包应仅用于自己有权检查的设备和网络。
第五步：从出口和不同情境复核
确认检测页展示的解析器是否符合预期，同时检查设备当前使用的出口网络信息。出口地址与 DNS 解析器不是一回事：出口看起来正常，不能证明 DNS 一定经过同一条通道；检测站点看到熟悉的解析器，也不能证明所有应用的查询都走了它。
分别在 IPv6 开启和关闭、浏览器 DoH 开启和关闭的条件下测试，并记录差异。若只有某一种组合出现异常，优先检查对应设置；若系统工具与浏览器结果不同，可能是应用采用了独立解析路径。修正配置后重跑标准测试和扩展测试，确认结果稳定。这样完成的加密连接DNS泄露的检测流程，比单看一次网页结果更可靠。
常见问题
检测页显示陌生解析器，就一定是泄露吗？
不一定。先对照服务配置，并在相同网络条件下复测；运营方名称和地理位置只能作为线索。
加密连接出口正常，为什么还要查 DNS？
出口核验关注的是网络流量从哪里对外访问，DNS 核验关注域名由谁解析，两者可能走不同路径。
只用一个 DNS 检测网站够吗？
可作为初筛，但建议重连后复测，并结合设备与浏览器设置判断，避免把单次缓存或偶发结果当成结论。
怎样才算完成检测？
明确预期解析器，检查系统和浏览器配置，进行重复查询，再对照解析器与出口信息；关键结果应在目标使用环境下复核。
