站点开启HTTP/3后，浏览器仍多走HTTP/2，老旧客户端甚至落到HTTP/1.1；Alt-Svc到QUIC握手之间却可能悄悄失败。排查不能只改Web配置，而要把DNS公告、响应头、UDP路径和TLS验证串成一条链路。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：赤鱼网络（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
浏览器首次访问先经TCP完成TLS握手并协商ALPN。服务端返回Alt-Svc响应头（如h3=443、ma=86400）后，浏览器才记录QUIC地址和有效期。收到公告不等于已用HTTP/3：它可能过期、被代理剥离，DNS中的HTTPS/SVCB记录也可能指向其他节点。
随后浏览器在UDP上发起QUIC连接建立。QUIC把TLS 1.3握手融入连接过程，并校验证书链、域名、签名算法及ALPN的h3支持，服务端还须提供传输参数。客户端发出Initial包却无响应，通常指向UDP端口放行、边界设备拦截或路径丢包；收到握手包后断开，则应检查TLS证书兼容性、TLS扩展和QUIC参数。失败后浏览器会保留TCP/TLS通道：协商出h2便按HTTP/2降级策略使用，h2不可用才退到HTTP/1.1。
判断时先看Network面板的Protocol、Remote Address与Security，并用无痕窗口排除Alt-Svc缓存。若发现Alt-Svc但QUIC失败，后续稳定走HTTP/2，问题通常位于QUIC路径。同一站点在不同网络一成一败，说明中间设备对UDP处理不同。
服务器侧确认UDP 443正在监听且公网可达，并检查防火墙、负载均衡器、NAT和安全软件是否只放行TCP。抓包应出现客户端Initial与服务端握手响应；无回包先查端口和路由，握手完成却断开，再核对TLS 1.3、证书链、SNI、ALPN及传输参数。可借助随身服务器切换公网出口，验证故障是否随出口变化。结合日志归因：无Alt-Svc查公告、代理和DNS；无QUIC包查UDP；握手被拒查TLS；仅个别客户端回落查证书兼容性、缓存和策略。
HTTP/3 通常由服务端通过 Alt-Svc响应头 宣告。浏览器解析后缓存目标地址和有效期，再尝试建立 QUIC连接建立：QUIC 在 UDP 上完成版本协商、TLS 1.3 握手与传输参数交换，全部成功后才发送 HTTP/3 请求。
若 UDP端口放行 失败，客户端往往收不到明确错误，只会因握手包被丢弃而等待超时，随后回退到 TCP。服务端未监听 UDP、负载均衡未映射 QUIC、CDN 未启用 UDP 时，现象也相近。因此要区分“未收到 Alt-Svc”“收到但连不上”“连接成功但请求失败”，不能只看页面最终能否打开。
浏览器禁用 QUIC 时可直接走 TCP，但 HTTP/2降级策略 仍依赖 TLS ALPN：CDN、WAF、Ingress 和源站都要协商 h2，上游也需允许 HTTP/2 over TLS。若 Alt-Svc 指向错误 IP、端口或证书主机名，回退后仍可能失败。网关还可能改写或剥离 Alt-Svc，导致 QUIC 流量始终无法触发。
TLS证书兼容性 是 QUIC 握手门槛。QUIC 使用 TLS 1.3，证书链须完整，SAN 须覆盖域名，签名算法、密钥用途及 OCSP stapling 都应被客户端接受；某些旧证书在 TCP TLS 下可用，在 QUIC 路径却会失败。Alt-Svc 的写法、端口和 max-age 也必须正确，错误缓存可能让浏览器持续重试坏入口。
检查清单：①用支持 HTTP/3 的 curl 执行 curl --http3 -v https://example.com，查看协商过程及失败阶段；②从外网测试 UDP 443，核对防火墙、安全组、NAT、CDN 与负载均衡配置；③用 tcpdump 抓取 UDP 443，确认 Initial 包发出且服务端有回包；④确认响应包含 Alt-Svc: h3=":443"; ma=...，且代理没有改写；⑤用 openssl s_client -connect example.com:443 -servername example.com -alpn h2 检查证书链、SAN 和 h2 协商；⑥在浏览器 DevTools 查看 Protocol 与 Alt-Svc 缓存，清除站点数据后复测；⑦分别测试 QUIC、HTTP/2、HTTP/1.1，记录耗时和状态码。
最终应建立双路径基线：QUIC 可用时验证 HTTP/3 性能，UDP 受限时确认能在预期时间内无损回退到 HTTP/2；同时持续监控 Alt-Svc 命中率、QUIC 握手失败率和降级耗时，避免“页面能打开”掩盖链路长期失效。
