05 · HTTP/2、HTTP/3 与 0-RTT
理解浏览器到 Cloudflare 与 Cloudflare 到源站的协议边界，安全启用 HTTP/3，并判断 0-RTT 是否适合应用。
编辑与核验：橙宝书编辑团队 ·
先记住边界
HTTP/3 和 0-RTT 的开关作用于访客到 Cloudflare 的连接，不代表 Cloudflare 使用 HTTP/3 回源。浏览器可以用 HTTP/3 到边缘，而边缘仍以受支持的 HTTP/1.1 或 HTTP/2 与源站通信。
详细说明
- 01访客
根据浏览器、操作系统和网络条件协商 HTTP/2 或 HTTP/3。
- 02Cloudflare 边缘
终止访客连接并应用 TLS、缓存与安全策略。
- 030-RTT
只影响返回客户端的恢复连接，并有重放风险边界。
- 04源站
接受另一段 HTTPS 回源连接；Full strict 负责证书验证。
能力对比
| 能力 | 传输基础 | 主要收益 | 适合先做什么 |
|---|---|---|---|
| HTTP/2 | TCP + TLS | 多路复用、头部压缩，广泛兼容 | 保持启用，作为可靠回退 |
| HTTP/3 | QUIC over UDP + TLS | 减少丢包时不同请求流互相阻塞 | 在真实移动网络与跨地区访问中验证 |
| 0-RTT | 恢复已有 TLS 会话 | 返回客户端可更早发送部分请求 | 先审计 GET/HEAD/OPTIONS 是否真正无副作用 |
HTTP/3 不是所有请求都一定更快。首次连接、网络允许 UDP 的程度、客户端实现、资源数量和源站耗时都会影响结果。它应与 HTTP/2 并存，让客户端协商，而不是为了一个协议标签关闭可靠回退。
启用 HTTP/3
确认边缘 HTTPS 正常
HTTP/3 依赖边缘证书。先确保 HTTPS 页面与静态资源能通过 Cloudflare 正常访问，并保存一份 HTTP/2 基线瀑布图。
开启 HTTP/3
在 Speed → Optimization → Protocol Optimization 开启 HTTP/3 (with QUIC)。当前所有套餐可用。设置传播后，用支持 HTTP/3 的浏览器访问测试主机名。
在浏览器观察协商结果
打开开发者工具 Network 表格的 Protocol 列，重新载入页面。h3 表示该请求使用 HTTP/3；h2 表示回退到 HTTP/2。一次看到 h2 不等于配置失败，浏览器缓存、UDP 网络策略和连接复用都可能影响结果。
用可用的命令行客户端交叉验证
curl --version
curl --http3 -sS -I https://www.example.com/只有 curl --version 显示 HTTP/3 能力时，第二条命令才有诊断意义。若本机 curl 不支持，使用浏览器或已确认支持 QUIC 的测试环境，不要把“客户端缺功能”误判为 Cloudflare 故障。
0-RTT 要单独做安全决策
0-RTT 默认关闭。它让曾经连接过的客户端在恢复会话时更早发送数据，但早期数据存在被重放的协议风险。Cloudflare 当前只接受 GET、HEAD、OPTIONS 的早期请求，不接受 POST；这仍不代表所有 GET 都安全。
GET 也可能写数据
若应用把删除、发信、付费、令牌兑换或一次性下载放在 GET 上，先修正接口语义，不要依靠 Cloudflare 的方法过滤掩盖问题。源站可用 Early-Data: 1 识别早期数据，并对敏感操作拒绝或要求正常握手后重试。
| 可以优先试验 | 应先排除 |
|---|---|
| 公共静态资源、无状态公开 GET | 登录跳转、单次令牌、签名下载 |
| 可重复读取且无计费副作用的 API | 用 GET 触发写操作的遗留接口 |
| 有明确重放测试和日志的测试主机 | 无法观察 Early-Data 的关键业务 |
验证不是只看 h3
- 同一地区对比 HTTP/2 与 HTTP/3 的多次样本，不用单次最快值下结论。
- 同时记录 DNS、连接、TLS、TTFB、下载时间和源站响应时间。
- 在 Wi-Fi、移动网络和限制 UDP 的网络分别测试协议回退。
- 若开启 0-RTT，检查源站是否收到
Early-Data，并回放同一请求验证无重复副作用。 - 出现异常时先关闭 0-RTT；HTTP/3 与 0-RTT 是两个开关，不要一起回滚。
下一篇进入 Cloudflare 默认缓存行为，先理解系统在没有自定义规则时会做什么。
官方来源
这篇内容帮你完成目标了吗？
内测反馈只在当前浏览器生成，不会自动上传。