HTTP/3失败但HTTP/2正常：从UDP、Alt-Svc到浏览器缓存的分层排查

一、先确认症状边界

记录完整URL、发生时间、浏览器与版本、网络类型、是否经过企业代理，以及错误文本。测试同域名的小页面和大资源，观察是首次访问慢、所有请求失败，还是只有部分资源卡住。

再比较同设备同网络中的另一个浏览器，以及同设备切换到另一条合法网络后的结果。一次只改变一个变量。不要同时清缓存、改DNS、关闭防火墙和切网络，否则无法判断恢复来自哪一步。

二、HTTP/2与HTTP/3走的路径不同

RFC 9113定义HTTP/2，它通常通过TLS中的ALPN协商，并运行在TCP连接之上。RFC 9114定义HTTP/3，它把HTTP语义映射到QUIC；QUIC使用UDP，并提供协议协商、流式复用和流量控制。

因此，HTTP/2成功只能证明TCP与对应TLS路径可用，不能证明UDP上的QUIC也可用。家庭路由器、防火墙、运营商路径、企业出口或服务端UDP监听异常，都可能造成“h2正常、h3失败”。

三、确认实际协商结果

浏览器开发者工具的Network面板通常能显示请求使用的协议，但列名和展示方式随浏览器变化。先保留一次失败请求和一次成功请求，比较协议、远端地址、时间分解与状态。

命令行可在工具明确支持时分别测试HTTP/2与HTTP/3。先检查客户端构建能力，不要看到命令参数存在就假设底层已包含QUIC支持。记录完整版本和能力输出，避免不同机器使用不同curl构建却得出矛盾结论。

四、理解Alt-Svc的作用

RFC 7838定义HTTP替代服务。服务器可通过 Alt-Svc 响应头告诉客户端：同一来源可在另一协议、主机或端口上访问。客户端可缓存这项信息，并在后续请求中选择替代服务。

例如服务器可能通过Alt-Svc宣布支持h3。浏览器第一次先走现有HTTPS连接，之后尝试QUIC。于是“首次正常、后续卡住”可能与替代服务缓存有关，而不只是普通HTTP缓存。

Alt-Svc不会改变页面地址栏中的来源，替代端点仍需为原始来源提供有效认证。错误证书、错误边缘映射或过长的缓存时间都会扩大配置错误的影响。

五、检查响应头与缓存时间

在成功的HTTP/2请求中查看是否存在 Alt-Svc，记录协议标识、端口和 ma。RFC 7838说明 ma 表示替代服务的新鲜时间；在有效期内，客户端可能继续用缓存项建立新连接。

不要仅通过清理全部浏览器数据验证。优先使用新的临时浏览器配置或明确的网络日志做对照，避免删除用户会话。若新配置正常而原配置失败，再针对替代服务状态、扩展和缓存逐项缩小范围。

六、验证UDP路径而不关闭全部防护

HTTP/3依赖QUIC的UDP路径。检查本地防火墙、路由器、企业安全设备和服务端安全组是否允许实际使用的UDP端口。仅放行测试所需来源、目标和端口，记录原规则并准备回退。

不要为了测试关闭整台主机防火墙。若切换到另一条网络后HTTP/3稳定，而原网络持续失败，可把边界缩小到本地接入或上游路径，但仍需结合服务端和其他客户端对照，避免把偶发边缘节点故障误判为家庭路由器问题。

七、区分完全阻断与间歇丢包

完全阻断通常表现为QUIC建连持续失败后回退，具体等待时间由客户端实现决定。间歇丢包则可能表现为首屏部分资源慢、长连接不稳或网络切换后停顿。

分别在空闲链路和上传占满时测试，记录中位延迟、尾延迟与丢包，而不是只看一次测速。UDP路径对队列、MTU和网络设备状态可能更敏感，但不能仅凭“UDP”二字认定根因。

八、检查服务端与边缘配置一致性

确认提供Alt-Svc的响应来自哪一层：源站、反向代理、CDN还是边缘函数。若响应宣告h3，实际UDP监听、证书、SNI和路由必须在对应端点一致可用。

多边缘节点环境要按请求时间、地区和解析地址分组。只有部分请求失败时，保存远端地址和可公开的请求标识，检查是否集中在某个节点。不要仅在源站本机执行一次请求就宣布公网HTTP/3正常。

九、注意网络切换后的缓存状态

RFC 7838指出，网络配置变化可能让缓存的替代服务变得不理想，未标记persist的条目应在客户端检测到变化时移除。实际浏览器的缓存和回退实现会有差异。

如果从办公网络切到热点后仍延续异常，对照新浏览器配置或完全退出并重新打开浏览器。不要通过修改系统时间让缓存过期，这会引发TLS和登录问题。

十、设计安全回退

HTTP/3不可用时，站点应让支持的客户端能够回到HTTP/2或HTTP/1.1，而不是让页面长期不可访问。短期缓解可以停止错误的h3宣告或修复UDP端点，但必须由站点管理员按变更流程执行，并同步缩短错误缓存的影响。

客户端侧临时禁用HTTP/3只适合诊断。验证完成后恢复原设置，再观察修复后的自动协商。若恢复后问题重现，说明服务器或路径根因仍在。

十一、完整验证步骤

1. 固定URL、设备、网络和测试时间。

2. 保存失败与成功请求的协议和时间分解。

3. 确认客户端确实支持HTTP/2与HTTP/3测试。

4. 查看Alt-Svc值、端口和新鲜时间。

5. 用HTTP/2建立可用基线。

6. 单独验证HTTP/3与UDP路径。

7. 用新浏览器配置区分缓存和扩展影响。

8. 切换一条合法网络，判断原接入路径是否参与。

9. 按边缘地址统计失败，检查服务端配置一致性。

10. 修复后恢复自动协商，跨多个缓存周期复验。

十二、常见错误

• 看到HTTP/2正常就认定网络完全正常。
• 永久关闭HTTP/3并把它当成根因修复。
• 清除全部浏览器数据，导致证据和登录状态丢失。
• 关闭整机防火墙测试UDP。
• 忽略Alt-Svc的缓存时间与替代端点。
• 只测源站，不测真实公网边缘节点。
• 同时修改DNS、代理、浏览器和网络。
• 用单次峰值测速判断QUIC质量。

十三、FAQ

HTTP/3一定比HTTP/2快吗？

不一定。HTTP/3具有低延迟建连和基于QUIC的流能力，但实际表现取决于网络路径、实现、缓存和服务器配置。

浏览器地址没变，为什么连接到另一端点？

Alt-Svc允许来源宣告替代服务。地址栏仍保持原来源，客户端在满足认证条件时可使用替代协议或端点。

清理普通HTTP缓存能清除Alt-Svc吗？

不一定。浏览器可能分别管理替代服务状态、网络状态和网页缓存。应使用浏览器支持的诊断方式或新配置做对照。

UDP被限制时网站一定打不开吗？

不一定。实现良好的客户端可回退到HTTP/2或HTTP/1.1；若回退过慢或失败，需继续检查客户端策略与服务器宣告。

十四、结论

HTTP/3失败而HTTP/2正常时，应沿“协议确认—Alt-Svc发现—UDP路径—浏览器状态—边缘配置”逐层缩小范围。临时回退是诊断手段，最终结果必须是在恢复自动协商后仍能稳定访问，并保留可复验的协议和路径证据。

核验来源

• RFC Editor：RFC 9113，HTTP/2，https://www.rfc-editor.org/info/rfc9113/（核验日期：2026-08-25）
• RFC Editor：RFC 9114，HTTP/3，https://www.rfc-editor.org/rfc/rfc9114.html（核验日期：2026-08-25）
• RFC Editor：RFC 7838，HTTP Alternative Services，https://www.rfc-editor.org/info/rfc7838/（核验日期：2026-08-25）