DoH 与 DoT 加密 DNS 协议对比详解

TL;DR

DoH 与 DoT 都加密 DNS 查询。抗 GFW：DoH > DoT（443 端口混在 HTTPS 里）。性能：DoT 略快 5-10ms（开销更小）。部署：两者都被 Sing-Box / Mihomo / Karing 原生支持。建议：墙内场景配 DoH，企业 / 海外场景配 DoT。配合代理客户端的 fakeip 模式，可彻底规避 DNS 污染。

DoH 与 DoT 是 IETF 在 2016-2018 年标准化的两种加密 DNS 协议。设计目标一致（让 DNS 查询不被中间人看到），但实现路径不同。在中文网络环境里，两者都是反 DNS 污染的关键基础设施。本篇按 RFC 出身 → 握手差异 → DPI → 性能 → 客户端 → 协同六块讲清楚。

RFC 出身

协议	标准	发布年	端口
DoT（DNS over TLS）	RFC 7858	2016	TCP 853
DoH（DNS over HTTPS）	RFC 8484	2018	TCP 443

更晚的 DoQ（DNS over QUIC, RFC 9250, 2022, UDP 853）和 ODoH（Oblivious DoH, 2021）暂时不在本文范围。

握手层与协议封装

DoT 数据包格式

TLS handshake → 853 端口
    ↓ TLS 通道建立
DNS query (RFC 1035 binary format) → TLS → server
    ↓
DNS response → TLS → client

DoT 是”把传统 UDP DNS 协议挪到 TCP + TLS 上”。每个查询：2 字节长度 + DNS 二进制报文。

DoH 数据包格式

HTTPS request → 443 端口
    ↓ TLS 通道建立
POST /dns-query HTTP/1.1
Content-Type: application/dns-message
Body: DNS query (RFC 1035 binary)
    ↓
HTTP/1.1 200 OK
Content-Type: application/dns-message
Body: DNS response

DoH 把 DNS 查询塞进 HTTP POST / GET 请求体。HTTP 头本身有开销，但能复用 HTTPS 连接。

DPI / GFW 抗性

DoT 的弱点：固定端口 853

任何流量到 853 端口都是 DoT（没有别的协议用这个端口）。GFW 在 2020 年起对 853 端口做了直接封锁——多数国内运营商网络下 853 不通。

DoH 的优势：混在 HTTPS 里

DoH 走 443，与所有 HTTPS 网页流量混在一起。DPI 要识别 DoH 需要看：

• SNI（如果 SNI 是 cloudflare-dns.com 仍可能被识别）
• HTTP/2 流量模式（小请求 + 小响应）
• 与已知 DoH 服务器的 IP 匹配

GFW 可以封”已知 DoH 服务器 IP”（如 1.1.1.1）但难以全面识别 DoH 流量本身。

自建 DoH 的反检测

如果你用自有域名 + 自建 DoH 服务器（如 adguardhome / sniproxy / nginx + dnsdist），SNI 是你自有域名，流量与普通 HTTPS 完全不可分。这是最稳的方案。

性能实测

环境：上海移动家宽 → Cloudflare DoH/DoT

协议	单次查询 RTT	1000 次平均	连接复用后
明文 UDP DNS	25 ms	28 ms	28 ms
DoT (cloudflare-dns.com:853)	45 ms	35 ms	30 ms
DoH (cloudflare-dns.com/dns-query)	50 ms	38 ms	32 ms

差距：DoT 比 DoH 快约 5 ms（HTTP 头开销）。但相比明文 UDP DNS 的加密开销约 +5-15 ms，对实际使用基本无感。

Sing-Box DoH/DoT 配置

{
  "dns": {
    "servers": [
      { "tag": "doh-cloudflare", "address": "https://cloudflare-dns.com/dns-query", "detour": "proxy" },
      { "tag": "dot-google", "address": "tls://8.8.8.8:853", "detour": "proxy" },
      { "tag": "domestic", "address": "tls://223.5.5.5:853", "detour": "direct" }
    ],
    "rules": [
      { "domain_suffix": [".cn"], "server": "domestic" }
    ],
    "fakeip": {
      "enabled": true,
      "inet4_range": "198.18.0.0/15"
    }
  }
}

要点：

• 主 DNS 走代理（detour: proxy）防本地 ISP 污染
• 国内域名走 AliDNS（直连）减少海外回路
• fakeip 模式由代理客户端分配虚拟 IP，DNS 不实际解析

Mihomo DoH/DoT 配置

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://cloudflare-dns.com/dns-query
    - https://dns.google/dns-query
    - tls://8.8.8.8:853
  fallback:
    - https://1.1.1.1/dns-query
    - tls://1.1.1.1:853
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29

要点：

• nameserver 是主查询（代理域名走这）
• fallback 是备用（应对主 DNS 故障）
• default-nameserver 用于解析上面 DoH/DoT 服务器的域名（明文 UDP 即可）

Karing / Hiddify

直接在 UI 里改：

• Karing：设置 → DNS → 选 “Cloudflare DoH” / “Google DoT” / 自定义
• Hiddify：DNS 配置 → 写 https://1.1.1.1/dns-query 或 tls://1.1.1.1:853

iOS / Android 系统级

iOS 14+ 系统级 DoH

在 iCloud 网站或第三方工具生成 .mobileconfig 配置文件，导入：

<key>DNSSettings</key>
<dict>
  <key>DNSProtocol</key>
  <string>HTTPS</string>
  <key>ServerURL</key>
  <string>https://cloudflare-dns.com/dns-query</string>
</dict>

Android 9+ 系统级 DoT

设置 → 网络与互联网 → 私人 DNS → “私人 DNS 提供商主机名” → 输入 dns.google

注意：如果你已经用了代理客户端的 TUN 模式 + 内置 DNS，不要再配系统级 DNS——会产生两条 DNS 路径，反而引入泄露。

公共 DoH / DoT 服务器对照表

提供商	DoH URL	DoT 主机	备注
Cloudflare	https://cloudflare-dns.com/dns-query	cloudflare-dns.com:853	速度最快
Cloudflare 1.1.1.2（家庭）	https://family.cloudflare-dns.com/dns-query	family.cloudflare-dns.com:853	阻成人内容
Google	https://dns.google/dns-query	dns.google:853	海外速度好
Quad9	https://dns.quad9.net/dns-query	dns.quad9.net:853	阻恶意域名
AdGuard	https://dns.adguard.com/dns-query	dns.adguard.com:853	阻广告
NextDNS	https://dns.nextdns.io/	.dns.nextdns.io:853	可定制
阿里 DoH	https://dns.alidns.com/dns-query	dns.alidns.com:853	国内可用
腾讯 DoH	https://doh.pub/dns-query	dot.pub:853	国内可用

DoH/DoT 不能解决的问题

• 目的污染：目标域名（如 youtube.com）被 GFW RST 阻断，DNS 解析正确但 TCP 三次握手即被打断。仍需代理 / VPN。
• SNI 嗅探阻断：目标域名 TLS ClientHello 的 SNI 字段被检测后 RST。需要 SNI 加密（ECH）或 VLESS Reality 这类伪装协议。
• 整网封锁：GFW 对部分海外 IP 段全段封锁。需要 IP 跳变 / CDN 中转。

加密 DNS 只解决”DNS 路径污染”。完整反审查体系还需要代理、SNI 伪装、IPv6 处理等多层方案。

与代理客户端协同的最佳实践

1. 代理客户端开 TUN 模式 + fakeip
2. 客户端 DNS 配 DoH（主）+ DoT（备）
3. 国内域名走运营商或阿里 DoH（直连）
4. 国外域名走代理 + DoH（避免泄漏到 ISP）
5. 关闭浏览器 / 系统层的独立 DNS 配置（避免双路径）

这套组合下，DNS 既加密、又不污染、也不暴露给 ISP。

相关阅读

• WebRTC 泄露检测与修复完整指南
• Clash Meta 与 Mihomo 客户端配置完整指南
• Sing-Box Android 配置 2026 完整教程

来源与最后核对

• RFC 7858（DoT）：datatracker.ietf.org/doc/html/rfc7858
• RFC 8484（DoH）：datatracker.ietf.org/doc/html/rfc8484
• Cloudflare DoH/DoT 文档：developers.cloudflare.com/1.1.1.1
• Sing-Box DNS 文档：sing-box.sagernet.org/configuration/dns

本文最后实际验证日期：2026-05-19。