DoH（DNS over HTTPS）和 DoT（DNS over TLS）是把域名查询放进加密通道发给解析器的两种方式。2026 年主流浏览器与部分系统已内置「安全 DNS」。它和 VPN/TUN 的隧道 DNS 叠在一起时，最常见的困惑不是「哪个更高级」，而是：你以为走了系统设置，实际问的是浏览器自己的解析器。
DoH / DoT 到底加密了什么
传统 DNS 查询多在 UDP/TCP 53 端口以近乎明文形式发出，路径上的网络设备容易看到你查询了哪些域名。DoH 与 DoT 把这次问答放进 TLS，降低沿途窃听与篡改的机会。
一个可独立引用的定义句：DoH/DoT 加密的是「问名字」这一跳，不是整台设备的上网出口。
| 方式 | 常见承载 | 谁发起 | 和 VPN 的关系 |
|---|---|---|---|
| 传统 DNS | UDP/TCP 53 | 系统或应用 | 可被隧道 DNS 接管，也可仍问运营商 |
| DoT | TLS（常为 853） | 系统或专用组件 | 仍是「解析器选择」，不自动进 VPN |
| DoH | HTTPS（常为 443） | 浏览器或系统 | 易绕过系统 DNS 与部分客户端规则 |
它不替代 VPN 是什么 里说的隧道：网页内容、连接出口、账号登录仍按各自路径走。
为什么会和 VPN DNS「打架」
DNS 泄漏检查 的核心对照是：解析器是否落在你期望的隧道侧。浏览器 DoH 把对照表撕开一角——系统 DNS 已经进隧道，浏览器却仍向 Cloudflare、Google 或其他 DoH 端点发查询（具体端点以浏览器设置为准）。
常见叠加结果：
- 系统设置显示隧道 DNS，检测页却列出公共 DoH 运营方；
- 分流规则按域名写了代理，解析却在规则之外完成，CDN 调度与出口地区不一致；
- Fake-IP / 虚拟 DNS 模式下，浏览器 DoH 根本不走客户端映射表，规则命中率下降（见 Fake-IP 说明）；
- 只关系统 VPN、不关 DoH，或相反，复测时变量没对齐，结论无法复现。
测试环境写法示例：2026 年 9 月，家庭宽带，Windows 11，同一浏览器先开系统 DNS 仅、再开浏览器「安全 DNS」，分别记录泄漏检测页上的解析器与客户端 DNS 日志。
三层对照表：浏览器、系统、客户端
排障时把解析路径拆成三层，一次只动一层：
| 层 | 你在哪里看 | 典型「绕过」信号 |
|---|---|---|
| 浏览器 | 设置里的安全 DNS / DoH 开关与自定义 URL | 检测页解析器随浏览器变，命令行 nslookup 不变 |
| 系统 | 网卡 DNS、私钥配置、系统「加密 DNS」项 | 全体应用跟着变，但独立 DoH 的浏览器例外 |
| VPN/TUN 客户端 | 隧道 DNS、虚拟 DNS、规则里的 DNS 动作 | 客户端日志显示已下发，检测页仍显示公共 DoH |
结果怎么读
| 现象 | 更可能的含义 | 下一步 |
|---|---|---|
| 系统已是隧道 DNS，检测页是公共 DoH | 浏览器 DoH 绕过系统 | 关闭或改成「使用当前系统解析器」后复测 |
| 关闭浏览器 DoH 后仍显示运营商 DNS | 隧道未接管系统 DNS | 按泄漏检查文查 TUN/权限/分流直连 |
| 命令行与浏览器结果长期不一致 | 双路径并存 | 先统一浏览器，再谈规则与 Fake-IP |
| 仅 IPv6 检测异常 | 双栈或 DoH 端点偏好 v6 | 对照 IPv6 泄漏检查 |
| 开了 DoH 后规则域名不命中 | 解析未进客户端 | 关 DoH，或让 DoH 端点本身走隧道且接受副作用 |
无法核对运营方名称时，写「据检测页显示」，不要写成确定的公司结论。
什么时候保留 DoH，什么时候关掉
更值得保留浏览器/系统 DoH 的情况：
- 设备没有可靠的隧道 DNS，你主要想减少咖啡店、酒店等路径上的明文查询与污染；
- 你接受「解析出口」可能与「网页出口」不完全同一家，并会用时间锚点复测 CDN 是否异常；
- 企业或学校环境禁止改系统 DNS，只允许浏览器侧加密 DNS。
更值得先关掉（或改为跟随系统）的情况：
- 正在验证 VPN/TUN 是否真正接管解析；
- 使用依赖客户端 Fake-IP 或域名规则集的 分流；
- 检测页与系统设置长期对不上，需要先消除最大变量；
- 你要让「问名字」和「建立连接」走同一条已选择的通道。
务实顺序：先让隧道 DNS 可验证，再决定是否在浏览器加回 DoH。反过来先堆开关，只会得到无法解释的截图。
和泄漏、分流、Fake-IP 放在同一清单
换浏览器大版本、重装客户端、或从系统代理切到 TUN 之后，建议固定四步：
- 记下浏览器安全 DNS 开关状态；
- 跑一次 DNS 泄漏检查，对照期望隧道 DNS；
- 抽查规则命中（应代理 / 应直连各一）；
- 若使用 Fake-IP，确认应用侧看到的是占位地址还是公网地址。
DoH/DoT 不处理 WebRTC 候选地址，也不替代 Kill Switch；那些仍按专文验证。它只回答：这次名字查询加密了没有、问的是谁。
常见误解
误解 1：开了 DoH = 开了 VPN。
DoH 只保护查询通道的一跳。网页出口、IP 暴露、指纹与账号登录不在其范围。
误解 2：DoH 一定比隧道 DNS 更隐私。
查询改问大型公共解析器，运营方仍可能看到解析元数据。隐私是「对谁可见」的选择，不是绝对消失。
误解 3：系统写了 1.1.1.1 就等于 DoH。
把公共解析器填进传统 DNS 字段，查询仍可能是未加密的 53 端口；是否 DoH/DoT 要看系统或浏览器是否启用了对应协议。
误解 4：检测页列出知名 DoH 运营方就是泄漏到运营商。
更常见是浏览器故意问了该运营方。泄漏到运营商的典型信号，仍是家庭宽带/路由器侧的解析器地址。
建议怎么落地
把 DoH/DoT 当成解析路径上的独立开关，而不是 VPN 的附属勋章。验证隧道时，先让浏览器跟随系统并关闭独立安全 DNS，确认泄漏检查与客户端日志一致；需要减少明文查询时，再显式打开 DoH，并接受「检测页会显示该 DoH 端点」。每次只改一层、写下 2026 年的测试日期与设备，结论才能在下次系统更新后复测。