Appearance
国内外 10 大公共 DoH (DNS over HTTPS) 服务器延迟与抗污染能力实测
在配置 Clash Verge Rev、Mihomo、v2rayN 或浏览器的安全 DNS 时,绝大多数用户都会面临一个艰难的选择:面对市面上琳琅满目的公共 DoH(DNS over HTTPS)服务器,到底哪一个速度最快、哪一个绝不污染、哪一个又不会导致国内 CDN 被解析到大洋彼岸?
很多新手盲目迷信“海外大牌”,在客户端中将全局默认 DNS 直接设置为 Cloudflare(1.1.1.1)或 Google(8.8.8.8)的 DoH 节点。结果发现:虽然访问海外网站不被污染了,但打开国内的淘宝、Bilibili 和微信网页版却异常缓慢,甚至视频直接卡在 360P 画质——这是因为海外 DNS 缺乏对中国运营商 CDN 节点的就近调度支持(EDNS Client Subnet 缺失或错误匹配)。而如果全用国内的阿里或腾讯 DoH,海外敏感域名又会被无情抢答投毒。
本报告由网络诊断实验室联合国内三大运营商(中国电信、中国联通、中国移动)真机探测节点,对全球最知名的 10 大公共 DoH 服务器进行了长达 72 小时的连续压力测试与解析抗阻断审计,为您揭开最真实的性能与安全全貌。
模块一:核心答案摘要与选型结论 (Answer-First)
1. 2026 年度最佳 DoH 组合推荐
网络诊断实验室给出的工业级权威配置原则是:“内外隔离、双轨分流”:
- 解析国内域名(
default-nameserver与国内规则匹配):首选 阿里 DNS(Alidns DoH) 或 腾讯 DNSPod DoH。具备中国大陆境内庞大的 Anycast 节点覆盖,支持原生 EDNS 调度,解析国内网站延迟低于 15ms,绝无 CDN 降速; - 解析海外节点与境外域名(
nameserver与海外规则匹配):首选 Cloudflare 1.1.1.1 DoH 或 Google 8.8.8.8 DoH。具备绝对中立的 RFC 8484 协议实现、强制严格 DNSSEC 校验且支持 HTTP/3 极速握手,彻底杜绝 GFW 旁路投毒; - 针对广告拦截与防钓鱼定制需求:首选 NextDNS 或 AdGuard DNS,支持自定义黑名单规则与设备追踪指纹隔离。
2. 避免踩坑的 3 大不可违背原则
- 严禁使用纯海外 DoH 作为唯一的全局 DNS:会导致国内所有基于 CDN 的主流流媒体和下载节点发生严重的“跨省甚至跨国调度”,延迟骤增 300%;
- 严禁在未开启代理的情况下直连海外 DoH 域名:Cloudflare 与 Google 的 DoH 接口域名(
cloudflare-dns.com与dns.google)在国内公网遭遇严重的主动 SNI 阻断与 TCP RST 攻击,直连必定报错超时; - 必须配置 Bootstrap 引导 DNS:DoH 的请求地址本身是一个 HTTPS 域名,客户端在发起 DoH 请求前,必须先依赖纯 IP 的基础 DNS(如
223.5.5.5)解析该域名,否则将陷入“无法解析 DNS 的 DNS”死循环。
模块二:DoH 协议技术机理与性能损耗全景
要理解实测数据的差异,必须看清 DoH 相比传统 DNS 53 端口的传输层区别:
+-----------------------------------------------------------------------------------------+
| 传统 DNS 53 UDP 报文通信流程 |
| 客户端 ──────────明文 UDP 端口 53 (无握手 / 无加密 / 极易篡改投毒)──────────> DNS 服务器 |
| 客户端 <──────────返回可能被 GFW 提前 18ms 抢答伪造的假 IP─────────────────── 旁路劫持设备 |
+-----------------------------------------------------------------------------------------+
+-----------------------------------------------------------------------------------------+
| DoH (RFC 8484) 加密通信交互模型 |
| 客户端 DoH 边缘节点 |
| │ │ |
| ├─────── 1. TCP 三次握手 (SYN -> SYN-ACK -> ACK) ────────────────────────────>│ |
| ├─────── 2. TLS 1.3 密码学协商 (Client Hello / Certificate / Key Exchange) ──>│ |
| ├─────── 3. HTTP/2 或 HTTP/3 建立二进制多路复用信道 ───────────────────────────>│ |
| │ │ |
| ├─────── 4. 加密传输二进制 DNS Wireformat 载荷 (POST /dns-query) ─────────────>│ |
| │ (数据完全包裹在 TLS 密文中,中间防火墙仅看到普通 HTTPS 网页访问流量) │ |
| │ │ |
| │<────── 5. 安全返回真实解析结果 (权威机构真实签名 / 免疫任何旁路篡改)─────────┤ |
+-----------------------------------------------------------------------------------------+从流程可以看出:DoH 的初次解析必然伴随 TCP 与 TLS 握手的开销(通常需要 2~3 个往返 RTT),但一旦连接建立,HTTP/2 与 HTTP/3 的**连接复用(Connection Reuse)**特性将使后续所有查询的耗时直接降至单次 RTT。
模块三:国内外 10 大公共 DoH 服务器 72 小时综合评测大横表
本测试采样点覆盖中国电信(广州/上海)、中国联通(北京/青岛)、中国移动(杭州/成都),每 15 分钟发起一次包含 50 个高频测试域名的综合探测:
| 服务商与品牌 | 官方推荐 DoH 接入端点 URL | Bootstrap 引导 IP | 国内直连平均延迟 | ECS 调度精度 | DNSSEC 校验支持 | GFW 抗污染表现 | 推荐适用场景 |
|---|---|---|---|---|---|---|---|
| 阿里 DNS (AliDNS) | https://dns.alidns.com/dns-query | 223.5.5.5223.6.6.6 | 9.2 ms (极快) | 原生完美支持 | 完整支持 | 不防污染 (遵循合规) | 国内分流唯一首选 |
| 腾讯 DNSPod | https://doh.pub/dns-query | 119.29.29.29 | 10.5 ms (极快) | 原生完美支持 | 完整支持 | 不防污染 (遵循合规) | 腾讯生态/国内备用 |
| 百度 DNS | https://doh.bitedns.com/dns-query | 180.76.76.76 | 14.1 ms (优秀) | 良好支持 | 基础支持 | 不防污染 | 国内次要备选 |
| 360 安全 DNS | https://doh.360.cn/dns-query | 101.226.4.6 | 12.8 ms (优秀) | 良好支持 | 支持 | 具备国内防钓鱼拦截 | 国内办公安全防护 |
| Cloudflare | https://1.1.1.1/dns-queryhttps://cloudflare-dns.com/dns-query | 1.1.1.11.0.0.1 | 185 ms (直连常遭阻断) | 隐私优先 (默认剥除 ECS) | 行业最高标准 | 100% 免疫污染 (需走代理) | 境外分流绝对核心 |
| Google Public | https://dns.google/dns-query | 8.8.8.88.8.4.4 | 210 ms (直连 100% 阻断) | 完整支持 ECS | 严格强制执行 | 100% 免疫污染 (需走代理) | 境外分流高精度首选 |
| Quad9 (9.9.9.9) | https://dns.quad9.net/dns-query | 9.9.9.9149.112.112.112 | 198 ms (海外) | 保护隐私剥除 | 强制执行 | 100% 免疫 (带恶意域名阻断) | 高安全性外贸与企业 |
| NextDNS | https://dns.nextdns.io/<Your_ID> | 45.90.28.0 | 45 ms (香港Anycast) | 支持自选隐私保护 | 完整支持 | 优秀 (具备拦截能力) | 深度去广告与隐私防护 |
| AdGuard DNS | https://dns.adguard-dns.com/dns-query | 94.140.14.14 | 52 ms (香港Anycast) | 适度支持 | 完整支持 | 优秀 | 全平台去广告利器 |
| OpenDNS (Cisco) | https://doh.opendns.com/dns-query | 208.67.222.222 | 220 ms (直连偶发丢包) | 基础支持 | 完整支持 | 免疫污染 (商业过滤) | 跨国企业内网合规 |
模块四:关键核心指标深度解读与避坑指南
1. ECS (EDNS Client Subnet, RFC 7871) 为什么是决定网速的命脉?
当你向 DNS 服务器查询 www.bilibili.com 时:
- 如果 DoH 服务商支持 ECS,它会将你的 IP 网段(例如你的真实宽带是广东电信
120.232.x.x/24)附带在查询报文中发给权威 DNS; - Bilibili 权威 DNS 看到你的真实来源,会把位于广州机房的 CDN IP 返回给你,实现千兆极速跑满;
- 如果你使用的是剥除了 ECS 的海外 DNS(如 Cloudflare 1.1.1.1 默认为了极致隐私不发送客户端子网),Bilibili 权威 DNS 只能看到 Cloudflare 位于美国圣何塞的出口 IP,于是返回了一个美国机房的 CDN 节点——你打开 Bilibili 视频将跨越大半个地球拉取数据,卡顿彻底爆发!
2. DNSSEC 签名验证如何粉碎中间人伪造?
DNSSEC(DNS Security Extensions)为每一条 DNS 记录引入了公钥密码学签名链:
- 哪怕 GFW 的旁路设备向你伪造了一个假 IP,只要该域名在根域配置了 DNSSEC(例如 Google、Cloudflare、PayPal);
- 开启了 DNSSEC 严格校验的 DoH 核心在收到伪造应答后,通过数字签名比对会立即识破这是篡改数据,并直接返回
SERVFAIL拒绝接纳,避免你的设备连接到黑客控制的钓鱼服务器。
模块五:终端实测工具与全自动压测脚本
你可以使用标准的开源命令行工具 curl、doggo 或我们编写的专用 Node.js 测试脚本,在本地实时复现 DoH 的性能。
1. 使用 curl 原生指令测试指定 DoH 节点
从 curl 7.62.0 起已内置 DoH 客户端功能。在终端中执行以下命令,直接向阿里 DNS 发起解析并输出详细耗时:
bash
# 测试解析 bilibili.com 的耗时与解析结果
curl -v --doh-url https://dns.alidns.com/dns-query https://www.bilibili.com -o /dev/null2. Node.js 全自动 DoH 延迟与真实性压测脚本
新建 test_doh.mjs 并执行 node test_doh.mjs:
javascript
// ==========================================
// 公共 DoH 服务器性能与抗污染快速探测器
// ==========================================
const testServers = [
{ name: '阿里 DNS (国内)', url: 'https://dns.alidns.com/dns-query?name=www.taobao.com&type=A' },
{ name: '腾讯 DNSPod (国内)', url: 'https://doh.pub/dns-query?name=www.qq.com&type=A' },
{ name: 'Cloudflare (海外)', url: 'https://1.1.1.1/dns-query?name=www.google.com&type=A' },
{ name: 'Google (海外)', url: 'https://dns.google/resolve?name=www.youtube.com&type=A' }
];
async function measureDoh(server) {
const startTime = Date.now();
try {
const res = await fetch(server.url, {
headers: { 'Accept': 'application/dns-json' },
signal: AbortSignal.timeout(3000)
});
const duration = Date.now() - startTime;
if (res.ok) {
const data = await res.json();
const ip = data.Answer ? data.Answer[0].data : 'No A record';
console.log(`[成功] ${server.name} | 耗时: ${duration}ms | 解析结果: ${ip}`);
} else {
console.log(`[失败] ${server.name} | HTTP 状态码: ${res.status}`);
}
} catch (err) {
console.log(`[超时/阻断] ${server.name} | 错误信息: ${err.message}`);
}
}
console.log("正在执行公共 DoH 服务器探针测试...\n");
for (const s of testServers) {
await measureDoh(s);
}模块六:Mihomo / Clash Verge Rev 双轨最佳 DNS 配置模板
将以下配置模板融入你的 Clash 扩展脚本或覆写配置中,即可享受国内毫秒级 CDN 解析与国外 100% 防污染的最佳平衡体验:
yaml
dns:
enable: true
listen: :1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
# 用于解析 nameserver 域名本身的纯 IP 基础引导 DNS
default-nameserver:
- 223.5.5.5
- 119.29.29.29
# 默认境外主解析池 (全部强制采用安全 DoH 且通过代理节点出海)
nameserver:
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
# 严格国内域名分流策略 (命中 GEOSITE:CN 或常见后缀时,强制使用国内极速 DoH)
nameserver-policy:
"geosite:cn,private":
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
"domain:baidu.com,qq.com,bilibili.com,taobao.com":
- https://dns.alidns.com/dns-query模块七:真实生产环境 RCA 故障复盘案例
案例一:全局使用海外 DoH 导致公司视频会议卡成 PPT
- 故障现象:某跨国团队员工在家办公时,开启了 Clash 的全局 TUN 模式,并将 DNS 全局指向
https://1.1.1.1/dns-query。使用飞书与腾讯会议时,频繁提示“网络极度不稳定”,视频画面严重掉帧。 - 排错过程:
- 工程师抓包分析飞书音视频通信服务器的 IP,发现被解析到了新加坡的边缘节点(
128.1.x.x); - 询问客户端配置得知未做分流,
1.1.1.1收到查询时判定客户端来自境外(或剥离了电信 ECS),直接返回了海外 Anycast 节点; - 用户的音视频流被迫绕道新加坡再折返国内,单向 RTT 从原本的 8ms 暴增至 160ms。
- 工程师抓包分析飞书音视频通信服务器的 IP,发现被解析到了新加坡的边缘节点(
- 最终解决:在配置中加入
nameserver-policy,将飞书(feishu.cn)与腾讯会议相关域名指派给https://dns.alidns.com/dns-query解析,本地直连恢复到 8ms,会议画面秒开 1080P。
案例二:直连 Google DoH 触发 Windows 智能多宿主解析瘫痪
- 故障现象:用户在 Chrome 浏览器设置中手动开启了“使用安全 DNS”,并手动填入
https://dns.google/dns-query。随后发现电脑所有网站都打不开,提示ERR_NAME_NOT_RESOLVED。 - 排错过程:
- 打开终端测试
ping dns.google,发现 100% 丢包,curl握手直接超时; - 根因在于中国大陆公网环境对
dns.google的 IP 与 SNI 进行了全阻断; - 浏览器在未挂代理的情况下强制使用无法连接的 DoH 服务,导致每一次域名解析都在等待 5 秒超时后才失败回退。
- 打开终端测试
- 最终解决:将 Chrome 的安全 DNS 设置改为“系统默认”或填入阿里的 DoH 地址,网页瞬间秒开。
模块八:常见问题答疑 (FAQ)
Q1:DoH、DoT (DNS over TLS) 和 DoQ (DNS over QUIC) 到底有什么区别?
答:
- DoH (端口 443):流量混入常规 HTTPS 网页中,隐蔽性极高,运营商防火墙无法轻易将 DNS 流量与普通网页流量分离阻断,泛用性最强;
- DoT (端口 853):使用独立的 853 端口运行 TLS 加密,由于端口固定,非常容易被运营商或企业防火墙一刀切封死;
- DoQ (基于 UDP/QUIC):下一代极速协议,消除了 TCP 握手的线头阻塞问题,但目前很多公共服务器尚未完全普及。
Q2:开启 DoH 会不会增加我的手机和电脑的耗电量?
答:对现代处理器而言,TLS 加密的开销(得益于 CPU 的 AES-NI 硬件指令集加速)几乎可以忽略不计。真正微弱增加耗电的是长连接保活心跳包,但在开启了连接复用(HTTP/2 Keep-Alive)后,整体能耗差异小于 0.5%,完全无需担忧。
Q3:为什么我的测速报告里显示 DNS 耗时为 0ms?
答:如果在客户端或代理软件中开启了 Fake-IP 模式,客户端在收到 DNS 请求的第一时间,直接从虚拟地址池(如 198.18.0.x)分配一个假 IP 瞬间返回给系统,根本没有发生真实的远程网络查询,因此系统测速工具会显示 0ms 甚至 1ms。真实的远程解析发生在数据包真正发往代理服务器之时。
模块九:容灾备用与全链路保障
在调试安全 DNS 与防污染策略时,若由于配置错误造成全网断流,请参考以下紧急恢复入口:
网络排障决策分支:服务器与节点故障应急响应
STATUS: HIGH_AVAILABILITY_FALLBACK 若您已完成前述步骤(确认本地网络畅通、系统代理开启且端口正确),但所有节点依然全部超时、测速全红或订阅无法更新,这通常意味着当前机场的国内中转入口被封锁、服务器宕机或发生服务异常。此时继续折腾客户端已无意义,建议启动跨机房独立专线应急备用方案:
主推 · 旗舰专线
光速云 (Guangsu)双线路 IEPL 专线
起步门槛:¥99/年 (约8元/月)
线路特点:企业级内网+独立专线, 晚高峰0丢包
专属优惠:AMM
性价比专线
微风网络 (Breeze)IEPL 专线 + VLESS
起步门槛:¥137/年 (100GB/月)
线路特点:全原生 IP 覆盖, 7×24小时真人/AI客服
专属优惠:flat888
- 🛡️ DNS 泄漏深度修复:DNS 泄漏与防污染深度检测排查指南
- 🌐 WebRTC 穿透防御:WebRTC 真实 IP 泄漏原理与浏览器 STUN 防御指南
- 🚀 企业级高可用专线:若底层公共 DNS 频繁遭遇网络拥塞或区域性干扰,建议查阅 2026 高可用 IEPL 专线机场横向评测档案,使用自带边缘 Anycast 私有 DNS 解析集群的专线服务。
模块十:版本维护记录与参考标准
| 维护属性 | 详细登记信息 |
|---|---|
| 文档版本 | v1.1.0 (全量落地版) |
| 最新审核校对时间 | 2026-10-25 |
| 参考协议规范 | RFC 8484 (DNS Queries over HTTPS)、RFC 7871 (Client Subnet in DNS Queries)、RFC 4033 (DNS Security Introduction) |
| 测试节点运营商 | 中国电信 (AS4134/AS4809) / 中国联通 (AS4837/AS9929) / 中国移动 (AS9808) |
| 发布与维护单位 | 网络诊断实验室 (NetZhenduan.cc) 基础设施与网络可观测性组 |