DoH / DoT / DoQ：加密 DNS 协议选择

摘要: 传统 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 地址格式

1
2
3
4
5

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 特有的问题。

图片来源：Heimdal Security

DNS over TLS (DoT)

原理

DoT 是最早标准化的加密 DNS 协议（RFC 7858，2016 年发布）。它的思路比 DoH 更直接：在 DNS 客户端和服务器之间建立一条 TLS 加密隧道，DNS 查询直接在这条加密隧道中传输，不经过 HTTP 层。

DoT 使用专用的 TCP 端口 853。客户端连接到服务器的 853 端口，完成 TLS 握手后，在加密通道中发送和接收标准格式的 DNS 消息。

常见 DoT 地址格式

1
2
3
4

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，2022 年发布）。它基于 QUIC 传输协议，使用 UDP 传输，默认端口为 853（与 DoT 相同的端口号，但因为 QUIC 跑在 UDP 上，所以不会冲突）。

QUIC 是 Google 开发、IETF 标准化的下一代传输协议，已经被 HTTP/3 采用。QUIC 将传输层和加密层合二为一，在 UDP 上实现了类似 TCP + TLS 的可靠传输和加密，同时还有一些独特优势。

常见 DoQ 地址格式

1
2

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 是目前在中国网络环境下唯一具有实际可用性的加密 DNS 协议。DoT 因为端口封锁在中国基本不可用，DoQ 因为生态不成熟和 UDP 限制也不推荐在生产环境使用。

在代理场景中的选择

推荐方案：国内 DoH 作为 nameserver

在代理客户端中，推荐使用国内 DoH 作为 nameserver：

1
2
3
4
5
6

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）

国际（通过代理访问，一般不需要配置）

在 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。