--- title: DoH / DoT / DoQ：加密 DNS 协议选择 date: 2026-05-10 categories: - DNS 专题 tags: - DoH - DoT - DoQ - DNS - 加密 excerpt: DoH、DoT、DoQ 三种加密 DNS 协议对比。在代理场景中推荐使用国内 DoH。 index_img: /images/posts/encrypted-dns.jpg --- > **摘要**: 传统 DNS 查询以明文传输，容易被监听和篡改（DNS 污染）。加密 DNS 协议通过加密 DNS 查询来保护隐私和防止篡改。主流的加密 DNS 协议包括 DNS over HTTPS (DoH)、DNS over TLS (DoT) 和 DNS over QUIC (DoQ)。本文对比三者的原理、优劣和在代理场景中的选择。 --- ## 为什么需要加密 DNS 传统 DNS 使用 UDP 协议的 53 端口，查询和响应内容完全明文，没有任何加密或完整性校验。这意味着网络路径上的任何节点都能看到你在查什么域名、得到了什么结果，也能随意篡改返回的结果。 具体来说，明文 DNS 面临以下威胁： **窃听。** 你的 ISP（网络运营商）可以完整记录你的所有 DNS 查询。你访问了哪些网站、什么时间访问、访问了多少次——DNS 日志里一清二楚。部分运营商会利用这些数据进行广告投放或用户画像分析。在公共 Wi-Fi 环境下，同一网络内的任何人都可以抓包看到你的 DNS 请求。 **篡改（DNS 污染）。** GFW 对明文 DNS 的利用是最直接的：当你查询被封锁域名的 IP 地址时，GFW 会抢先返回一个伪造的响应，把域名指向错误的 IP。这就是 DNS 污染。由于传统 DNS 没有验证机制，你的设备无法分辨收到的响应是来自真正的 DNS 服务器还是 GFW 的注入。结果就是，即使你的代理完全正常，DNS 污染也会在更前面的环节把连接搞坏。 **中间人攻击。** 在没有加密的情况下，网络中间的任何设备（路由器、交换机、透明代理）都可以拦截 DNS 请求、修改响应内容，或者把请求重定向到另一个 DNS 服务器。用户对此完全无感知。 加密 DNS 协议解决两个核心问题： 1. **隐私（Privacy）**——加密传输使第三方无法看到你的 DNS 查询内容 2. **完整性（Integrity）**——加密和认证机制使第三方无法篡改 DNS 响应 目前主流的加密 DNS 协议有三种：DoH、DoT 和 DoQ。它们的目标相同，但实现方式不同，各有优劣。 --- ## DNS over HTTPS (DoH) ### 原理 DoH 将 DNS 查询封装在标准的 HTTPS 请求中。DNS 客户端向 DoH 服务器发送一个 HTTPS 请求（通常是 POST 或 GET），请求体中包含 DNS 查询的二进制数据（wire format），服务器返回的 HTTPS 响应体中包含 DNS 应答。 整个过程跑在标准的 HTTPS 协议栈上：TCP 连接 → TLS 握手 → HTTP/2 或 HTTP/3 传输。DNS 查询在外部观察者看来就是一个普通的 HTTPS 请求，与你访问网页时发送的 HTTPS 请求在形式上没有区别。 DoH 使用 TCP 端口 443——这与所有 HTTPS 网站使用的端口完全相同。 ### 常见 DoH 地址格式 ``` https://doh.pub/dns-query # 腾讯 DNSPod https://dns.alidns.com/dns-query # 阿里 DNS https://cloudflare-dns.com/dns-query # Cloudflare https://dns.google/dns-query # Google https://doh.360.cn/dns-query # 360 DNS ``` ### 优势 **极难封锁。** DoH 运行在 443 端口上，这是全球 HTTPS 流量使用的标准端口。封锁 443 端口等于封锁整个互联网，任何防火墙都不会这么做。而且 DoH 流量在网络层面上与普通 HTTPS 请求无法区分——它们使用相同的端口、相同的 TLS 协议、相同的 HTTP 协议。要精确识别并阻断 DoH 流量，需要进行深度包检测（DPI）来分析连接的目标域名（通过 SNI 或 IP 地址），这比封锁一个专用端口的成本高得多。 **客户端支持广泛。** 几乎所有主流代理客户端（Clash、sing-box、V2Ray、Shadowrocket、Surge、Quantumult X）都支持 DoH。主流浏览器（Chrome、Firefox、Edge、Safari）内置了 DoH 支持。Windows、macOS、iOS、Android 的操作系统层面也已支持 DoH。这意味着无论你用什么设备、什么软件，DoH 都能用。 **可穿透 HTTP 代理。** 在某些受限网络环境中（如企业网络只允许通过 HTTP 代理上网），DoH 可以通过 HTTP 代理正常工作，因为它本身就是 HTTP 协议。 **连接复用。** DoH 基于 HTTP/2，支持在一个 TCP 连接上多路复用多个 DNS 查询。建立连接后，后续查询不需要重新握手，延迟显著降低。 ### 劣势 **首次查询延迟较高。** 第一次连接 DoH 服务器时，需要完成 TCP 三次握手 + TLS 握手 + HTTP 协商，总共可能需要 2-3 个 RTT。相比传统 DNS 的单次 UDP 往返，首次查询确实更慢。不过，连接建立后会保持，后续查询延迟与传统 DNS 基本持平。 **HTTP 协议开销。** 每个 DNS 查询都需要包装成 HTTP 请求，增加了 HTTP 头部等额外数据。对于单次查询来说，数据量的增加是可以忽略的，但相比 DoT 直接在 TLS 上传输 DNS 数据，DoH 确实多了一层 HTTP 的封装。 **DNS 服务器可见客户端 IP。** DoH 服务器能看到你的真实源 IP 地址。虽然加密保护了查询内容不被第三方看到，但 DNS 服务器本身仍然知道是谁在查询什么域名。这是所有直连式加密 DNS 协议的共同局限，不是 DoH 特有的问题。 ![DNS over HTTPS 工作原理](/images/inline/doh-diagram.jpg) *图片来源：[Heimdal Security](https://heimdalsecurity.com/)* --- ## DNS over TLS (DoT) ### 原理 DoT 是最早标准化的加密 DNS 协议（RFC 7858，2016 年发布）。它的思路比 DoH 更直接：在 DNS 客户端和服务器之间建立一条 TLS 加密隧道，DNS 查询直接在这条加密隧道中传输，不经过 HTTP 层。 DoT 使用专用的 TCP 端口 853。客户端连接到服务器的 853 端口，完成 TLS 握手后，在加密通道中发送和接收标准格式的 DNS 消息。 ### 常见 DoT 地址格式 ``` tls://dns.alidns.com:853 # 阿里 DNS tls://1.1.1.1:853 # Cloudflare tls://8.8.8.8:853 # Google tls://dot.pub:853 # 腾讯 DNSPod ``` ### 优势 **协议开销更低。** DoT 直接在 TLS 上传输 DNS 消息，不需要 HTTP 层的封装（HTTP 头部、分帧等）。每次查询的数据量比 DoH 略小。 **纯 DNS 解析速度略快。** 在不考虑封锁的理想环境下，DoT 由于少了 HTTP 层的处理，单次查询的延迟比 DoH 略低（通常只差几毫秒，实际体感不明显）。 **协议设计简洁。** DoT 是专门为 DNS 加密设计的，不依赖复杂的 HTTP 协议栈。实现和调试相对简单。 ### 劣势 **极易被封锁——这是 DoT 最致命的缺点。** DoT 使用专用端口 853，这个端口除了加密 DNS 没有其他用途。防火墙只需要一条规则——阻断所有目标端口为 853 的 TCP 连接——就能彻底封杀 DoT。不需要深度包检测，不需要分析流量内容，单纯的端口封锁就够了。 **GFW 已经在封锁 853 端口。** 在中国大陆的网络环境中，连接境外服务器的 853 端口经常不通或不稳定。即使连接国内 DoT 服务器，也可能因为运营商层面的策略而不可靠。这意味着在中国实际使用中，DoT 的可用性远不如 DoH。 **客户端支持不如 DoH 广泛。** 虽然大部分代理客户端支持 DoT，但主流浏览器对 DoT 的原生支持很少。在需要系统级 DNS 加密的场景下，DoT 的可选方案比 DoH 少。 **一旦被识别就是靶子。** 853 端口的流量100%是加密 DNS，这个端口本身就是一个信号。网络管理员或 ISP 看到你在连接某个 IP 的 853 端口，立刻就知道你在使用加密 DNS。这在某些环境下可能引起额外注意。 --- ## DNS over QUIC (DoQ) ### 原理 DoQ 是最新的加密 DNS 协议（[RFC 9250](https://datatracker.ietf.org/doc/rfc9250/)，2022 年发布）。它基于 QUIC 传输协议，使用 UDP 传输，默认端口为 853（与 DoT 相同的端口号，但因为 QUIC 跑在 UDP 上，所以不会冲突）。 QUIC 是 Google 开发、IETF 标准化的下一代传输协议，已经被 HTTP/3 采用。QUIC 将传输层和加密层合二为一，在 UDP 上实现了类似 TCP + TLS 的可靠传输和加密，同时还有一些独特优势。 ### 常见 DoQ 地址格式 ``` quic://dns.adguard.com:853 # AdGuard quic://unfiltered.adguard-dns.com:853 ``` ### 优势 **0-RTT 连接建立。** QUIC 支持 0-RTT（零往返时间）连接恢复：如果客户端之前连接过某个 DoQ 服务器，再次连接时可以在第一个数据包中就携带 DNS 查询，完全省去握手延迟。这是三种加密 DNS 协议中理论延迟最低的。 **多路复用无队头阻塞。** QUIC 的多路复用是在传输层实现的，不同 DNS 查询在不同的 QUIC stream 上独立传输。一个查询的丢包或延迟不会影响其他查询。而 DoH 和 DoT 基于 TCP，如果一个数据包丢失，后续所有数据包都要等待重传（队头阻塞）。 **连接迁移。** QUIC 使用连接 ID 而非 IP+端口 来标识连接。当设备网络切换时（比如从 Wi-Fi 切换到 4G），QUIC 连接可以无缝迁移而不需要重新握手。 ### 劣势 **服务器支持极为有限。** 截至 2026 年，提供 DoQ 服务的 DNS 服务器屈指可数。国内几乎没有公共 DoQ 服务器，国际上也只有 AdGuard 等少数几家提供。这直接限制了 DoQ 的实用性。 **客户端支持有限。** 虽然 AdGuard、部分版本的 sing-box 等支持 DoQ，但主流代理客户端（如 Clash Meta/mihomo）对 DoQ 的支持不够成熟或尚未实现。浏览器和操作系统层面更是基本没有原生 DoQ 支持。 **UDP 在中国可能受限。** 部分运营商和网络环境对 UDP 流量有限速或封锁策略。QUIC 流量（包括 DoQ）在某些网络下可能表现不稳定，甚至完全不可用。这与 DoT 被封锁 853 端口是不同的问题，但结果类似——在中国不够可靠。 **协议太新，生态不成熟。** DoQ 标准化时间很短，整个生态还在早期阶段。遇到问题时，可参考的文档、社区讨论、排查经验都比 DoH 和 DoT 少得多。在生产环境中使用需要承担更高的不确定性。 --- ## 三种协议对比 | 特性 | DoH | DoT | DoQ | |------|-----|-----|-----| | 标准 | RFC 8484 (2018) | RFC 7858 (2016) | RFC 9250 (2022) | | 传输层 | HTTPS (TCP 443) | TLS (TCP 853) | QUIC (UDP 853) | | 抗封锁能力 | 强 | 弱 | 弱 | | 首次连接延迟 | 较高（2-3 RTT） | 中等（2 RTT） | 低（1 RTT，恢复连接 0-RTT） | | 协议开销 | 中等（HTTP 层） | 较低 | 较低 | | 部署成熟度 | 高 | 中 | 低 | | 客户端支持 | 广泛 | 较广 | 有限 | | 可用服务器数量 | 很多 | 较多 | 很少 | | 在中国的可用性 | 好 | 差（端口常被封） | 差（UDP 限制） | | 多路复用 | 有（HTTP/2） | 无原生支持 | 有（QUIC stream） | | 队头阻塞 | 存在（TCP 层） | 存在（TCP 层） | 不存在 | 综合来看，DoH 是目前在中国网络环境下唯一具有实际可用性的加密 DNS 协议。DoT 因为端口封锁在中国基本不可用，DoQ 因为生态不成熟和 UDP 限制也不推荐在生产环境使用。 --- ## 在代理场景中的选择 ### 推荐方案：国内 DoH 作为 nameserver 在代理客户端中，推荐使用国内 DoH 作为 nameserver： ```yaml dns: enable: true enhanced-mode: fake-ip nameserver: - https://doh.pub/dns-query # 腾讯 DNSPod DoH - https://dns.alidns.com/dns-query # 阿里云 DoH ``` 这个配置只需要两行就够了。不需要配置 fallback，不需要配置 DoT，不需要配置国际 DNS。 ### 为什么推荐 DoH **可靠性第一。** 443 端口不会被封锁，DoH 流量与正常 HTTPS 不可区分。在中国任何网络环境下，DoH 都能稳定工作。代理客户端的 DNS 需要 7x24 可用——如果 DNS 不通，整个代理就废了。可靠性是选择加密 DNS 协议最重要的标准，没有之一。 **国内 DoH 服务器延迟极低。** 腾讯和阿里的 DoH 服务器在国内有大量节点，从中国大陆连接延迟通常在 10-30ms 以内。连接建立后复用连接，后续查询延迟更低。对于 Fake-IP 模式下只需要解析国内直连域名的场景，国内 DoH 完全够用。 **不需要国际 DoH。** 在 Fake-IP 模式下，走代理的域名根本不在本地解析——它们由远端代理节点负责。本地 DNS 只解析直连域名（基本全是国内域名），所以国内 DoH 就够了。配置 Cloudflare 或 Google 的 DoH 不仅多余，反而因为需要出境连接而增加延迟和不确定性。 **配置最简单。** 不需要纠结 DoT 端口通不通、DoQ 客户端支不支持。两个国内 DoH 地址，配完收工。 ### 为什么不推荐 DoT 在中国代理场景下，DoT 没有任何优于 DoH 的地方： - **端口 853 被封锁的风险太高。** GFW 和部分运营商已经对 853 端口实施了不同程度的限制。你的 DoT 今天能用，不代表明天还能用。一旦端口被封，你的整个 DNS 解析就断了。 - **"延迟略低"的优势可以忽略。** DoT 比 DoH 省去了 HTTP 层，理论延迟低几毫秒。但在实际使用中，这几毫秒的差距完全感知不到。而 DoT 因为端口问题带来的可用性风险，远超这点延迟优势。 - **在代理场景中没有额外好处。** 代理客户端只需要一个能用的 DNS 来解析直连域名。DoH 完全能胜任，不需要为了理论上微不足道的性能差异而承担可用性风险。 ### 为什么不推荐 DoQ（目前） DoQ 的技术设计确实先进，但截至 2026 年，还不适合在代理场景中作为主力 DNS 使用： - **可用服务器太少。** 国内没有公共 DoQ 服务器，国际上只有 AdGuard 等少数几家。没有国内服务器意味着延迟高、连接不稳定。 - **客户端支持不成熟。** 主流代理客户端对 DoQ 的支持参差不齐，有些根本不支持，有些虽然支持但实现不够稳定。 - **UDP 在中国受限。** 部分运营商对 UDP 有 QoS 限制甚至丢包，这直接影响 QUIC 协议的可靠性。 - **未来可期。** 随着 QUIC/HTTP/3 的普及，DoQ 的生态会逐步成熟。等到国内有稳定的 DoQ 服务器、主流客户端完善了 DoQ 支持，可以重新评估。但现在不是换到 DoQ 的时候。 ### 注意事项 **Fake-IP 模式下，nameserver 只解析直连域名。** 走代理的域名由远端节点解析，本地 DNS 不参与。所以 nameserver 里只需要配置国内 DNS，不需要配置国际 DNS。 **不需要配置 fallback。** 在 Fake-IP 模式下，不存在"国内 DNS 被污染导致走错规则"的问题。路由决策基于域名而非 IP，DNS 污染影响不了分流准确性。fallback 是 Redir-Host 时代的产物，在 Fake-IP + DoH 的架构下没有意义。 **浏览器内置 DoH 可能冲突。** Chrome、Firefox 等浏览器有自己的 DoH 设置。在 TUN 模式下，代理客户端会接管所有 DNS 请求，浏览器的 DoH 设置不会生效，不冲突。但在系统代理模式下，浏览器可能绕过代理客户端的 DNS 直接使用自己的 DoH，导致解析结果与预期不符。建议在使用代理客户端时关闭浏览器内置的 DoH 功能，让代理客户端统一处理。 --- ## 常用 DoH 服务器 ### 国内（推荐用于 nameserver） | 服务商 | DoH 地址 | 说明 | |--------|---------|------| | [腾讯 DNSPod](https://www.dnspod.cn/) | `https://doh.pub/dns-query` | 推荐，稳定快速，国内节点多 | | [阿里云 DNS](https://alidns.com/) | `https://dns.alidns.com/dns-query` | 推荐，覆盖广，延迟低 | | 360 DNS | `https://doh.360.cn/dns-query` | 备选，覆盖一般 | ### 国际（通过代理访问，一般不需要配置） | 服务商 | DoH 地址 | 说明 | |--------|---------|------| | [Cloudflare](https://developers.cloudflare.com/1.1.1.1/) | `https://cloudflare-dns.com/dns-query` | 全球最快之一 | | Google | `https://dns.google/dns-query` | 知名度最高 | | Quad9 | `https://dns.quad9.net/dns-query` | 安全优先，过滤恶意域名 | 在 Fake-IP 代理架构下，国际 DoH 服务器无需手动配置——代理节点在境外解析时会自动使用当地的 DNS。 --- ## 常见问题 **Q：普通用户需要手动配置加密 DNS 吗？** 如果你已经在使用代理客户端并且配置了 Fake-IP 模式 + 国内 DoH 作为 nameserver，你的 DNS 隐私和安全已经得到了充分保护。直连域名通过加密 DoH 解析，代理域名在远端解析，本地根本不产生明文 DNS 查询。不需要再额外在系统层面或浏览器层面配置加密 DNS。 **Q：浏览器的 DoH 和代理客户端的 DNS 会冲突吗？** 取决于代理客户端的工作模式。在 TUN 模式下，代理客户端接管了系统网络栈，所有 DNS 请求（包括浏览器发出的 DoH 请求）都会被代理客户端拦截和处理，浏览器的 DoH 设置实际上不会生效。在系统代理模式下，浏览器可能绕过代理客户端的 DNS 处理，直接使用自己配置的 DoH 服务器进行解析。这可能导致解析结果与代理客户端的分流规则不匹配。建议在系统代理模式下关闭浏览器内置的 DoH，让代理客户端统一管理 DNS。 **Q：DoH 会影响网速吗？** 首次连接 DoH 服务器时需要完成 TLS 握手，可能增加几十毫秒的延迟。但连接建立后会保持复用，后续 DNS 查询的延迟与传统明文 DNS 基本相同。对整体上网速度的影响可以忽略不计。在 Fake-IP 模式下，走代理的域名在本地甚至不需要做真正的 DNS 解析（返回假 IP 是瞬间完成的），所以 DoH 的延迟只影响直连域名的解析，影响范围更小。 **Q：用了 DoH 还需要用 Fake-IP 吗？** 需要，两者解决的是不同层面的问题。DoH 保护的是 DNS 查询过程——让第三方无法窃听或篡改你的 DNS 请求和响应。Fake-IP 保护的是查询本身是否发生——走代理的域名根本不在本地解析，避免 DNS 查询行为暴露你的访问意图。即使用了 DoH，如果本地对 google.com 做了 DNS 查询（哪怕是加密的），ISP 仍然能通过目标 IP（DoH 服务器的 IP）和流量模式推断你在使用加密 DNS。而 Fake-IP 直接让这个查询不存在。最佳实践是两者结合使用：Fake-IP + 国内 DoH。 **Q：自建 DNS 服务器比用公共 DoH 更安全吗？** 自建 DNS 递归服务器（如 AdGuard Home、Pi-hole + Unbound）可以消除对第三方 DNS 服务商的信任依赖。但在代理场景下，这通常不是必需的。Fake-IP 模式下，你的 nameserver DNS 只解析国内直连域名（如 baidu.com、taobao.com），这些域名本身不敏感。使用腾讯或阿里的公共 DoH 解析这些国内域名，隐私风险极低。自建 DNS 的运维成本（服务器维护、DNS 记录更新、上游 DNS 选择）远大于它带来的边际安全收益。除非你有特殊的隐私需求或网络控制需求，否则不建议在代理场景中自建 DNS。