CDN 开启 HTTP/3 后，大多数用户访问正常，少数网络却出现首屏变慢、连接超时，甚至完全打不开。这类故障通常集中在 QUIC 使用的 UDP 443、HTTP/3 广告、浏览器缓存和 HTTP/2 回退链路。排查时需要先确认请求实际用了 h3 还是 h2，再区分是 CDN 边缘、客户端网络，还是自建服务端的 UDP 配置问题。
先判断故障是否只发生在 HTTP/3
HTTP/3 把 HTTP 语义运行在 QUIC 之上，QUIC 默认使用 UDP。它与常见的 HTTP/2 over TCP 不是同一条传输路径。某个网络允许 TCP 443，不代表 UDP 443 一定可用。
先用同一台设备、同一个域名做两组测试。测试环境中的 curl 必须带 HTTP/3 支持，可以先查看版本信息：
curl -V
输出中包含 HTTP3，再继续测试：
curl --http3 -sS -o /dev/null -D - \
-w 'http_version=%{http_version}\n' \
https://www.example.com/
curl --http2 -sS -o /dev/null -D - \
-w 'http_version=%{http_version}\n' \
https://www.example.com/--http3 允许 curl 在 HTTP/3 不可用时回退，适合观察普通客户端的访问结果。需要验证“只走 HTTP/3 能否成功”时，再使用：
curl --http3-only -I https://www.example.com/
如果 HTTP/2 正常、--http3-only 失败，问题范围已经缩小到 QUIC、UDP 443、HTTP/3 广告或客户端支持。两种协议都失败，则应继续检查 DNS、证书、域名绑定、CDN 配置和源站状态，不能把故障全部归到 HTTP/3。
浏览器也可以辅助确认。打开开发者工具的 Network 面板，显示 Protocol 列，重新加载页面，查看主文档和静态资源使用的是 h3、h2 还是 http/1.1。只看“HTTP/3 已开启”的控制台开关，无法证明当前请求已经走上 h3。
只有部分网络异常，重点检查 UDP 443
家庭宽带正常、公司 Wi-Fi 或校园网异常，是很典型的 UDP 路径问题。企业防火墙、VPN、访客网络、运营商设备和旧式 NAT 可能丢弃、限速或错误处理 UDP 443。客户端发出的 QUIC 数据包得不到回应时，浏览器通常会等待一段时间，再改走 TCP 443 上的 HTTP/2，因此用户感受到的是首个请求明显变慢。
可以让同一台设备分别连接家庭宽带、手机热点、公司网络和 VPN 复测。若问题随网络切换而出现或消失，浏览器和网站代码通常不是首要怀疑对象。应检查出口防火墙、上网行为管理、VPN 分流和 UDP 会话超时设置。
UDP 扫描结果只能作为线索。QUIC 服务不会像 TCP 一样完成三次握手，部分扫描工具会把无响应标记为 open|filtered。更可靠的证据来自实际 HTTP/3 请求、边缘日志、抓包结果和跨网络对比。
托管 CDN 与自建 HTTP/3 的检查位置不同
使用托管 CDN 时，HTTP/3 通常终止在 CDN 边缘。访客通过 QUIC 连接边缘节点，CDN 回源仍可能使用 HTTP/2 或 HTTP/1.1。此时在源站安全组开放 UDP 443，往往不能解决访客侧的 HTTP/3 故障，还会扩大源站暴露面。
托管 CDN 应检查以下项目：
HTTP/3 是否对当前域名和实际使用的分发配置生效；
证书、SNI 和域名绑定是否覆盖该主机名；
CDN 是否仍保留 TCP 443 的 HTTP/2 或 HTTP/1.1 服务；
边缘监控中 UDP、QUIC 握手和协议回退是否出现异常；
配置变更是否已经传播到全部边缘节点。
如果 Nginx、Caddy、Envoy、HAProxy 或其他网关在自己的服务器上直接终止 HTTP/3，检查范围才包括云安全组、主机防火墙、负载均衡器、NAT 和容器端口映射。TCP 443 与 UDP 443 是两条独立规则，放行其中一条不会自动放行另一条。改动前保存现有规则，并限制到实际提供服务的主机，避免用“全部 UDP 放行”替代准确配置。
检查 Alt-Svc 与 DNS HTTPS 记录是否还在发布 h3
客户端需要知道站点支持 HTTP/3。常见发现方式包括响应中的 Alt-Svc，以及 DNS HTTPS 记录中的协议参数。例如站点可能在 HTTP/2 响应中返回：
Alt-Svc: h3=":443"; ma=86400
ma 表示这条替代服务信息可以缓存多长时间。如果已经关闭 HTTP/3，却仍持续发送 h3 广告，或者客户端还保留着旧的 Alt-Svc 缓存，就可能反复尝试不可达的 QUIC 端点。反过来，控制台已经开启 HTTP/3，但响应和 DNS 都没有发布可用的 h3 信息，客户端也可能继续使用 h2。
排查时从一个确定可用的 HTTP/2 请求开始，保存完整响应头，查看 Alt-Svc：
curl --http2 -sS -D - -o /dev/null https://www.example.com/
同时查询域名的 HTTPS 记录，核对 alpn、目标主机和端口是否与当前部署一致：
dig HTTPS example.com
修改 HTTP/3 端口、边缘主机或 DNS 配置后，要同时处理旧广告的有效期。临时关闭 HTTP/3 时，应停止发布失效的 h3 入口，并保留 TCP 443。只改服务端监听，不处理 Alt-Svc 或 HTTPS 记录，会让部分客户端在缓存有效期内继续尝试旧路径。
回退机制不完整，会把“变慢”放大成“打不开”
正常部署应同时提供 HTTP/3 和基于 TCP 的 HTTP/2 或 HTTP/1.1。UDP 443 受阻时，客户端仍能通过 TCP 443 完成访问。HTTP/3 可以作为优先路径，但不应成为网站唯一可用的传输协议。
如果用户完全打不开，重点核对以下情况：
TCP 443 被误关，只剩 UDP 443；
HTTP/2 或 HTTP/1.1 在边缘被禁用；
TCP 与 UDP 指向不同的负载均衡器，其中一条配置过期；
两条路径使用了不同证书、SNI 或虚拟主机配置；
防火墙对 UDP 采用静默丢弃，客户端回退等待时间被明显拉长；
页面主域名可回退，但关键 API、字体、图片或第三方子域没有可用的 TCP 路径。
故障恢复阶段可以临时停止发布 h3 广告，让新连接稳定走 h2，同时保留现有配置以便回滚。确认 TCP 路径恢复后，再修复 UDP 443 并重新灰度开启 HTTP/3。不要通过关闭 TLS 校验或放开全部防火墙规则来掩盖协议配置问题。
修复后按网络与协议做交叉验证
一次成功访问不能证明问题已经消失。至少保留下面四组结果：
HTTP/3-only 请求成功，实际协议显示为 HTTP/3；
HTTP/2 请求成功，证书、状态码和内容均正常；
UDP 443 受限的测试网络仍能通过 h2 打开页面；
家庭宽带、手机热点、公司网络和 VPN 中不再出现明显的首连超时。
再检查主文档、API 和关键静态资源，避免只验证首页。浏览器开发者工具、curl 输出、CDN 边缘日志和防火墙日志应能指向同一条结论。
长期运行时，可以分别观察 h3 与 h2 的请求量、握手失败、连接建立时间和回退比例。HTTP/3 开关本身不是优化结果。UDP 443 可达、h3 广告准确、TCP 443 回退可用，这三项同时成立，HTTP/3 才不会把少数网络用户挡在站点之外。
参考资料
IETF RFC 9000：QUIC: A UDP-Based Multiplexed and Secure Transport
IETF RFC 9114：HTTP/3
IETF RFC 9460：Service Binding and Parameter Specification via the DNS（SVCB and HTTPS Resource Records）
curl 官方文档：HTTP/3
Cloudflare Developers：HTTP/3 (with QUIC)
资料核验日期：2026 年 9 月 30 日。
