三种加密 DNS 协议安全强度相当，差别在端口、封装层与生态。按你的设备和场景对号入座，不用纠结。
端口、传输层、延迟、抗封锁、生态成熟度一次看清
| 对比维度 | DoH | DoT | DoQ |
|---|---|---|---|
| 标准 | RFC 8484（2018） | RFC 7858（2016）/ 8310 | RFC 9250（2022） |
| 底层传输 | TCP + TLS + HTTP | TCP + TLS | UDP + QUIC |
| 默认端口 | 443/TCP | 853/TCP | 853/UDP（可 443/UDP） |
| 流量特征 | 与 HTTPS 网页完全混在一起 | 853 端口独立，特征明显 | UDP，443 变体可混入 |
| 抗封锁能力 | 强（难单独识别屏蔽） | 弱（端口易被封） | 中（依赖 UDP 443 不被限速） |
| 协议开销 / 延迟 | 略高（带 HTTP 头） | 低（无 HTTP 层） | 最低（0-RTT、无队头阻塞） |
| 连接复用 | HTTP/2 多路复用 | 单条 TLS 长连接 | QUIC stream + 连接迁移 |
| 生态成熟度 | 高（Chrome/Edge/Firefox、Win11） | 高（安卓私人 DNS、iOS、路由器） | 较低（递归软件/公共解析器先行） |
| 典型场景 | 浏览器、封锁规避 | 系统级全局加密 | 弱网、高性能递归通道 |
五个常见场景，直接给结论
三大浏览器的「安全 DNS」原生只提供 DoH 接口，填 https://服务器/dns-query 即可。Firefox 还支持自定义 DoH 服务器与回退策略。浏览器里不用折腾 DoT。
Android 9+ 的「私人 DNS」就是系统级 DoT，填服务商主机名即可，全系统 Wi-Fi/移动数据生效，无需 App。这是 DoT 在移动平台最成熟的落地。
iOS 通过加密 DNS 描述文件（.mobileconfig）配置，底层走 DoT。安装描述文件后全局生效，无需常驻 App。
路由器固件原生支持 DoT 上游的比例最高，填 tls://服务器 后全家设备一次生效。需要全屋加密又不想逐台配置时首选。
服务器到上游公共解析器取结果，用 DoT 最稳妥；若跑 AdGuard Home 等支持 DoQ 的递归软件，可在弱网或高并发链路下改用 DoQ 降低延迟。
Windows 11 在「网络 → DNS 服务器分配」里原生支持 DoH，填 https://服务器/dns-query 即可系统级加密，无需第三方软件。
关于同时开多个加密 DNS 的正确姿势
很多人会问：我能不能浏览器开 DoH、手机开 DoT，再在路由器上也开一个？答案是可以，但要理解「作用范围」这个概念，而不是无脑叠加。
浏览器的 DoH 只作用于浏览器这一个应用发出的 DNS 请求；系统级 DoT 作用于整机。在一台已经用系统 DoT 的电脑上，浏览器再开自己的 DoH，两者是「上层覆盖下层」的关系——浏览器请求走 DoH，其他应用走系统 DoT，通常不会互相干扰。
真正需要避免的，是在系统层面同时配置两个不同服务商的加密 DNS（例如系统 DoT 指向 A 服务商、某个网络工具又把系统 DNS 改成 B 服务商的 DoH）。这会让解析路径不可预期，排障时一头雾水。建议：系统级只保留一个主加密 DNS，浏览器可单独选另一个。
无论选哪种，都要确认失败回退行为：RFC 8310 要求证书校验失败时不要悄悄降级回明文 DNS，否则加密形同虚设。Firefox 等浏览器提供「仅加密、失败则报警」的模式，推荐开启。
抗封锁优先选 DoH（443 混淆）；低开销、全局覆盖优先选 DoT（853）；追求极致低延迟且接受新协议，选 DoQ。三者并非互斥的竞品，而是同一目标（加密 DNS）在不同传输层上的实现，按场景组合即可。