Nginx在浏览器不支持HTTP/2时静默降级至HTTP/1.1，排查关键在于验证真实协议协商结果而非配置是否存在：通过Chrome DevTools Network面板勾选Protocol确认是否显示h2，或用curl -I --http2检查响应是否为HTTP/2 200；若失败，需结合alt-svc头、TLS版本及ALPN支持度分析客户端兼容性。
浏览器不支持 HTTP/2 时，Nginx 不会报错，而是静默降级到 HTTP/1.1——问题表现为“明明配了 http2 却没生效”，但日志里找不到线索。排查重点不是找错误，而是确认协商是否真的失败、失败原因是否在客户端侧。
确认当前连接实际使用的协议版本
别依赖配置文件是否写了 http2，要验证真实行为：
- 打开 Chrome 或 Edge 的 DevTools → Network 标签页 → 右键表头勾选 Protocol → 刷新页面，观察所有请求的协议列是否显示
h2；若全是http/1.1，说明未走 HTTP/2 - 用命令行验证：
curl -I --http2 https://your-domain.com，若返回HTTP/2 200且无重定向，说明服务端基础通路正常；若返回HTTP/1.1，需进一步查协商环节 - 检查响应头中是否有
alt-svc字段（如alt-svc: h2=":443"; ma=86400），这是服务端通告 HTTP/2 能力的信号，但客户端是否采纳取决于自身支持度
识别典型不支持 HTTP/2 的客户端场景
并非所有“老设备”都完全不支持，关键是看 TLS 和 ALPN 能力是否达标：
- Windows XP + IE8/IE9：无 TLS 1.2 支持，无法完成 HTTP/2 必需的握手，必然降级
- Android 4.4 以下系统：底层 OpenSSL 版本过低（h2
- 某些定制 WebView（如旧版微信内置浏览器）：可能禁用 ALPN 或硬编码只接受 HTTP/1.1，即使服务端支持也连不上 h2
- cURL 7.47 以下或 OpenSSL ：执行
curl --http2会直接报错或退回到 HTTP/1.1，不能作为兼容性测试依据
用 OpenSSL 工具直连验证 ALPN 协商结果
绕过浏览器，确认服务端是否正确通告 h2：
- 运行：
openssl s_client -alpn h2 -connect your-domain.com:443 -servername your-domain.com 2>/dev/null | grep "ALPN protocol" - 若输出
ALPN protocol: h2，说明 Nginx 和 OpenSSL 层已正确配置并通告，问题大概率出在客户端不支持 ALPN 或拒绝该协议 - 若输出为空或
ALPN protocol: http/1.1，说明服务端未成功启用 ALPN（常见于 CDN 中间层拦截、OpenSSL 链接错误、或 ssl_protocols 禁用了 TLSv1.2+）
排除中间层干扰（CDN、WAF、负载均衡）
很多“客户端不支持”其实是中间设备导致的假象：
- Cloudflare 免费版默认终止在 TLS 1.2，且不透传 ALPN，后端 Nginx 看不到客户端的 ALPN 请求，自然无法协商 h2
- 企业级 WAF 或 LB 若未开启 ALPN 透传或强制使用 TLS 1.1，会切断 h2 升级路径
- 验证方法：绕过 CDN 直连服务器 IP（确保 DNS 解析到源站），再用上述
openssl s_client和curl --http2测试；若直连成功而走 CDN 失败，问题就在中间层
