DoH把DNS查询封装在HTTPS中，DoT则使用专门的TLS连接。二者都能保护客户端到解析器之间的查询，但不能简单等同于“开了就没有DNS泄露”。浏览器、操作系统、代理和其他应用可能各用一套解析路径。
DoH与DoT对比
| 项目 | DoH | DoT |
|---|---|---|
| 传输 | HTTPS | DNS over TLS专用连接 |
| 常见端口 | 通常443 | 通常853 |
| HTTP代理兼容 | 作为HTTPS请求可能经代理 | 需CONNECT与端口策略支持 |
| 流量识别 | 与HTTPS混合 | 端口和协议更明确 |
| 应用范围 | 常见于浏览器或应用 | 常见于系统/网关解析器 |
浏览器安全DNS覆盖哪些请求
浏览器开启DoH，通常只影响浏览器自身解析。终端、Git、游戏、系统服务和其他应用仍可使用操作系统DNS。判断泄露时应分别测试每个应用，不要用浏览器一个页面代表整台设备。
HTTP代理下DNS由谁解析
普通HTTP请求使用绝对URL时，代理常需要解析目标；HTTPS CONNECT携带主机名时也常由代理解析目标，但客户端仍需解析代理自身。不同客户端可能先本地解析或提交IP。应查看代理日志和本地DNS请求，而不是靠协议名称推断。
SOCKS5的远端DNS为何要实测
SOCKS5协议支持以域名作为目标，但客户端是提交域名还是先解析成IP由实现决定。某些配置区分本地与远端DNS。测试应使用仅代理侧可解析或专门授权域名，并观察本地解析器。
Split DNS为何与公共DoH冲突
企业内部域名只在组织DNS中存在。浏览器强制使用公共DoH后，内部站点可能无法解析，或得到错误公网地址。合理方案是按管理策略使用企业DoH/DoT、指定域名回退或系统解析，而不是无条件绕过。
DNS加密不等于目标隐藏
即使DNS查询加密，后续连接的目标IP仍对网络可见，TLS握手中的信息也可能暴露部分元数据，具体取决于协议版本和部署。DoH/DoT保护查询链路，不提供完整匿名性。
证书错误应该检查什么
DoH和DoT客户端都应验证解析器证书、域名、CA和系统时间。企业TLS检查可能影响DoH，DoT也可能被防火墙阻断。不要关闭证书验证来“保证解析”。
缓存为何导致测试结果不一致
浏览器、操作系统、应用、代理和解析器都有缓存。切换DoH或代理后，旧地址可能继续使用。测试前记录TTL和缓存层，使用新授权子域或等待过期，不要频繁清空整个生产DNS缓存。
DNS泄露应怎样定义
先定义预期路径：哪些应用应经企业DNS、哪些请求可由代理解析、是否允许本地网络解析。所谓泄露，是实际查询离开了预期受控路径。没有预期模型，只看检测网站列出的解析器，很容易误判。
DNS泄露基础可参考DNS泄露的成因与检查方法。
企业网络的合规边界
组织可能通过DNS阻断恶意域名、满足审计和Split DNS。用户不应绕过明确的安全策略。管理员也应说明数据用途、保留期限和例外机制，并尽量减少查询日志中的个人信息。
验证矩阵
- 记录浏览器、系统和应用DNS配置；
- 测试直连、HTTP代理和SOCKS路径；
- 观察本地DNS、代理解析和DoH/DoT连接；
- 分别测试公网与内部域名；
- 检查IPv4、IPv6和缓存；
- 验证解析器证书和失败回退；
- 对照组织预期判断是否泄露。
结论
DoH、DoT与代理的关键是解析责任。先确定每个应用把域名交给谁，再检查Split DNS、证书、缓存和失败回退，才能准确判断加密DNS是否生效以及是否偏离受控路径。
