DoH和DoT哪个好？DNS加密协议选型对比（性能+隐私+兼容性）

　　DNS加密这件事，讨论了好几年，但真正做选型决策的时候，很多人还是卡在同一个问题上：DoH和DoT都能加密DNS查询，到底该选哪个?这个问题的答案不是“哪个更好”，而是“哪个更适合你的场景”。DoH和DoT的设计目标从一开始就不一样——一个为浏览器而生，一个为操作系统而生。理解了这一点，选型就没有悬念了。

　　一个根本性的分歧：谁在控制DNS

　　IETF在制定这两个协议时，出发点完全不同。DoT的标准化工作始于2015年4月，2016年5月正式成为RFC 7858。它的设计场景是操作系统层面的stub resolver——也就是你电脑或手机上负责发起DNS查询的那个组件。

　　DoH的标准化工作晚了两年多，2017年12月才开始，2018年10月正式成为RFC 8484。它的设计场景是浏览器和Web应用，而不是操作系统。

　　这个时间差和场景差，直接决定了两者的技术路线分歧。

　　DoT的做法很“保守”：DNS协议本身不变，只是把它塞进TLS加密通道里，跑在专用的853端口上。IETF的文档里说得很直白——DoT“在操作系统和递归解析器里都容易实现”，但它“在操作系统中的实现很稀缺”。

　　DoH的做法更“激进”：它把DNS查询变成HTTP消息，通过HTTPS传输，跑在443端口上。结果是“在浏览器和递归解析器中都容易实现，规范还没完成就出现了大量实现”。

　　一个细节值得注意：DoT在推出时“似乎没有争议”，因为人们假设计算机会被配置为使用用户已经信任的同一个递归解析器。而DoH“很快就变得有争议”，因为Firefox开始测试使用一个“不一定被用户信任的云提供商”。

　　这句话点出了两者最本质的差异：DoT倾向于维持用户和解析器之间的信任关系，DoH倾向于让浏览器厂商替用户做选择。

　　性能：谁更快?

　　性能对比这件事，实验室数据和真实体验的差距可能很大。但把多个维度的测试结果拼起来，还是能看出一些规律。

　　但学术界的数据要复杂得多。一篇2026年4月发表的论文测试了DoT和DoH在并发查询下的表现，结果很有意思：单次查询时，DoT的平均响应时间是18.324毫秒，DoH是18.742毫秒，差距不到0.5毫秒。但并发查询时，两者都出现了严重的性能退化——DoT飙升到679.505毫秒，DoH是634.020毫秒，两者的标准偏差都接近200毫秒。

　　这篇论文的解释是：证书验证过程消耗CPU资源，并发查询时CPU资源争抢导致查询时间暴增。这意味着在高负载场景下，两者的性能差异可能被CPU瓶颈掩盖，真正重要的是硬件资源是否充足。

　　另一个影响性能的关键因素是HTTP版本。一篇学术研究指出，DoH通过HTTP/1.1传输时存在严重的队头阻塞问题，延迟可能增加0.1到1秒，但HTTP/2版本的DoH“更有前景，延迟与明文DNS相近”。这说明DoH的性能高度依赖实现质量，而不是协议本身。

　　一个来自真实世界的观察：DoH/3(基于QUIC的DoH)和DoQ在丢包或高延迟网络中表现更好，因为它们消除了TCP队头阻塞，支持流级别的恢复。如果你的网络环境不稳定，DoH/3比DoT更有优势。

　　隐私：加密之外，还有多少暴露

　　两者都使用TLS加密，所以“查询内容”本身是安全的。但隐私的含义远不止于此。

　　DoT的隐私问题在于853端口。 这个端口是专用端口，网络管理员一眼就能看出“这是DNS加密流量”。在企业网络中，很多防火墙直接封853端口，导致DoT根本连不上。DoT“通常被封锁”。

　　DoH的隐私优势在于“混淆”。 因为走443端口，DoH流量和普通HTTPS流量从外面看没有区别。网络监控设备无法通过端口判断这是DNS查询还是网页浏览。这让DoH在受限网络环境下更难被阻断。

　　但DoH的隐私优势有一个代价：它让网络层面的安全管控失效。ScienceDirect上的一篇2024年论文指出，DoH加密DNS查询后，“网络管理员检查和过滤DNS流量的能力被复杂化”，恶意软件可以利用DoH隐藏命令控制通信。论文还提到一个更深的隐私隐患：即使加密了内容，攻击者仍然可以通过分析DNS查询的大小和时间模式来推断用户的浏览活动。

　　IETF的RFC 8484本身也承认，DoH“必须使用满足HTTPS要求的安全传输”，但HTTP层的元数据——比如SNI、连接时长、数据包大小——仍然是暴露的。

　　ISC.org在2019年的一篇评论里提出了一个更宏观的担忧：DoH可能导致DNS控制权从ISP向浏览器厂商和云提供商集中。文章引用了Mozilla的明确表态——“我们试图将收集和变现用户数据的权力从ISP转移走”——并评论道，“DoH的部署可能加剧互联网的集中化，削弱独立的网络域，进一步助长CDN和集中式托管服务提供商的霸权”。

　　这个担忧在今天看来依然成立。

　　兼容性：谁更“好用”

　　兼容性不能只看“支持不支持”，还要看“在什么层面支持”和“用户能不能控制”。

　　DoT的兼容性特征是：系统级支持，应用级缺失。 Android 9+原生支持DoT，macOS 11+和iOS 14+同时支持DoH和DoT，Windows 11和Windows Server 2022支持DoH但不支持DoT(系统层面)。DoT一旦在操作系统层面配置好，所有使用系统DNS的应用都会自动受益。但DoT在浏览器中的支持几乎为零——Chrome和Firefox都不提供DoT选项。

　　DoH的兼容性特征是：应用级支持，系统级后来追上。 Chrome、Firefox、Opera都内置了DoH支持。Firefox从2020年开始对美国用户默认启用DoH。Windows 11和macOS也支持DoH。但DoH的配置通常是按应用逐个进行的——你在Firefox里开了DoH，Chrome里不一定开;你在系统层面配了DoH，某些应用可能还是走传统DNS。

　　一个关键差异：谁能控制DNS查询走哪条路。

　　在DoT模式下，操作系统把DNS查询发给用户配置的递归解析器——通常是ISP的解析器，或者用户手动指定的解析器。网络管理员可以通过DHCP或IPv6 RA来分发DNS配置，企业网络的安全策略得以生效。

　　在DoH模式下，浏览器可以绕过操作系统的DNS配置，直接连接到自己的DoH解析器。IETF的文档指出，Firefox会“硬编码DoH解析器的URL，覆盖操作系统配置的解析器”，这“可能干扰网络管理员部署DNS安全策略的方式”。

　　这就是为什么ISC.org把DoH描述为“让网络管理员无法在不解密所有HTTPS流量的情况下阻断DoH”。对于企业网络来说，这是一个实质性的管理问题。

　　选型判断：按场景倒推

　　个人用户，浏览器上网为主：DoH更合适。浏览器内置支持，配置简单，443端口不容易被封锁。如果你用的是Firefox或Chrome，直接启用DoH就能获得加密保护，不需要折腾系统设置。

　　企业网络，需要统一管控DNS：DoT更合适。系统级配置一次，所有应用受益;853端口明确可识别，防火墙和安全策略可以基于端口做规则。DoH在企业环境中的“隐蔽性”反而是缺点——它让安全团队失去了DNS层面的可见性。

　　路由器/家庭网络部署：DoT通常是更务实的选择。很多路由器固件(如OpenWrt、pfSense)支持DoT，配置在路由器层面可以覆盖所有连接设备。DoH的路由器支持相对有限，而且DoH的按应用配置模式在路由器上很难实现。

　　受限网络环境(如某些国家或企业)：DoH更可能穿透。443端口通常不会被封(封了正常网页也访问不了)，而853端口在很多地方被直接阻断。如果你需要绕过DNS封锁或审查，DoH是更现实的选择。

　　追求最新技术：DoH/3(基于HTTP/3的DoH)或DoQ值得关注。一篇2025年的研究建议“默认优先使用DoH/3或DoQ”，因为它们“性能更好、更安全、握手更快、延迟更低”。DoQ没有HTTP层，理论上开销更小，但支持它的解析器还不多。