DNS 测试页面显示的解析器位置，与网页连接使用的出口位置不是同一个指标。看到陌生地区或运营商，不能立即认定全部流量绕过代理；看到解析器与节点同地区，也不能证明所有应用都按预期分流。判断之前，应先明确自己希望哪些查询经过哪条路径。
测试页面实际观察了什么
这类测试通常让浏览器触发对特定域名的查询，再从服务端观察是谁向权威服务器提问。页面最终列出的往往是递归解析服务对外使用的地址，而不是电脑网卡上配置的地址。解析服务还可能具有多层转发和多个出口，因此结果可能超过一个。
地址的地理标签也只是第三方数据库给出的描述。公共解析服务采用分布式部署时，其注册地址、对外查询地址和实际接入地点未必一致。因此应优先记录解析服务名称和网络归属，再把地理信息当作辅助线索，不能仅凭地图上的距离判断隐私或速度。
网页自身的访问请求走另一条路径。浏览器先解析域名，再建立连接，代理也可能接收域名后在远端解析。测试页面只能覆盖这次浏览器行为，不能代表游戏、系统更新、终端和后台程序。需要分别定义这些应用的接管范围。
先写出预期，再看结果
一种需求是所有外部查询都交给指定加密解析服务；另一种需求是本地服务使用局域网解析，外部业务由代理侧解析。两种设计都可以合理，关键在于与自己的网络条件一致。若只写“不能泄漏”，却不定义允许的解析器和业务例外，就无法判定测试结果。
把链条分成应用、系统解析、客户端解析、上游解析四段。浏览器开启自己的安全解析功能时，可能不使用系统设置；客户端接管普通查询时，也不自动意味着接管了应用自行建立的加密连接。具体要看入站模式与路由，而不是看开关名称。
例如，假设系统设置指向本地路由器，而浏览器直接使用另一解析服务。测试出现该服务，只能说明本次查询走了浏览器选择的路径。要判断是否违反预期，需要结合浏览器设置、连接日志和出口结果。这个例子是排查方法说明，并非本站测量结果。
建立两项独立检查
第一项检查名称查询。记录测试时间、浏览器、解析设置、测试返回的解析服务以及客户端是否记录到查询。第二项检查目标连接。观察同一时间的连接日志和出口地址，确认命中规则与节点。不要把两个页面间隔很久的结果拼成一条链条，因为期间自动切换可能改变条件。
为了减少缓存干扰，可以使用测试服务生成的新域名，或关闭页面后按服务说明重新开始。不要为了测试而清空所有系统数据或重置整个浏览器。缓存会影响有没有新查询出现，但不会自动等于泄漏；日志没有查询也可能只是命中了已有缓存。
如果需要抓包，仅在自己的设备和授权网络上进行，并优先限制到相关时间段。抓不到普通 DNS 包，不能证明没有名称查询，因为它可能经过加密连接，也可能由远端完成。应把抓包结果与应用设置联合解释，不能把“未看到”写成绝对不存在。
加密与出口控制需要分别处理
DoH 为查询提供基于 HTTPS 的传输方式，但加密本身不规定必须走哪个代理出口。直接连接到公共 DoH 服务，和通过代理连接到同一个服务，会留下不同的网络路径。解析提供者仍参与处理查询，因此也不能把启用加密描述为对所有参与方完全匿名。
DNSSEC 的目标又不同，它关注验证数据来源与完整性，不是隐藏查询内容。将加密传输、数据验证和路由选择分开理解，能避免为了“防泄漏”同时乱开多个功能。每项变更都应有明确问题与验证方式。
在双栈环境中，还要检查两种地址族。浏览器可能通过一个地址族连接解析服务，再通过另一个连接网站。只看一个出口检测页面会遗漏情况。详细步骤可参考双栈分流核验，不要简单把所有异常归因于某个地址族。
结果应该如何记录
一份有用的结论可以写成：“在这台设备、这个浏览器和该配置下，本次新增查询由预期解析服务处理，目标新连接使用指定出口。”它明确限定范围，也方便之后复测。不要写“已经彻底无泄漏”，因为后台程序与其他网络尚未检查。
若结果与预期不符，先恢复最小配置，逐一检查应用自己的解析、系统设置和客户端接管方式。遇到解析服务器无法启动，可继续阅读加密解析的引导依赖；遇到命中规则不符，则按分流规则验证处理。把解析和连接分开记录，通常比反复更换解析器更快接近原因。
还有一种容易误判的结果是测试列表为空。空白可能来自测试脚本未执行、广告过滤拦截测试域名，或服务端等待超时。先确认页面完成了测试流程，再查看错误信息；没有列出解析器并不等于所有查询都被安全隐藏。
参考资料
- RFC 8484：DNS over HTTPS，核验日期：2026-10-15。
- mihomo DNS 配置，核验日期：2026-10-15。