应分场景按设备能力配置tls策略：通过$ssl_protocol与ua联合统计识别真实客户端，为旧设备设独立子域名及兼容server块，同步调整后端proxy_ssl配置，并渐进淘汰低版本tls。
排查 Nginx 开启 HTTP/2 后部分老旧客户端连接失败，核心是识别哪些客户端因协议或 TLS 能力不足而无法完成 ALPN 协商，进而降级失败或直接中断。这类问题通常不报明显错误码，而是表现为白屏、ERR_SSL_PROTOCOL_ERROR、ERR_HTTP2_PROTOCOL_ERROR 或静默超时。
确认客户端是否支持 HTTP/2 协商基础条件
HTTP/2 在浏览器端依赖 TLS 层的 ALPN 扩展协商，老旧客户端往往缺失该能力：
- OpenSSL
- Android 4.4 以下系统 WebView 不支持 ALPN；IE on Windows XP / IE8–10 全系列不支持 HTTP/2
- 某些企业定制浏览器、旧版 IoT 设备 SDK 或内嵌 UA 的 App 也常禁用或未实现 ALPN
可通过访问 https://http2.pro 或使用 curl -I --http2 https://your-domain.com 验证现代客户端是否走 h2；对疑似老旧设备，用 openssl s_client -alpn h2 -connect your-domain.com:443 检查服务端是否返回 ALPN protocol: h2，若无则说明协商未触发。
检查 Nginx TLS 协议与加密套件兼容性
即使启用了 http2，若 TLS 配置过于激进，老旧但支持 TLSv1.2 的客户端也可能握手失败：
- 确保
ssl_protocols至少保留TLSv1.2（不要仅写TLSv1.3） - 避免强制启用仅 TLS 1.3 支持的加密套件（如
TLS_AES_128_GCM_SHA256），混入兼容性更强的套件，例如：ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; - 禁用
ssl_prefer_server_ciphers off（默认值），让客户端优先选择其支持的最强套件
验证 Nginx 配置是否真正启用并隔离干扰
常见配置陷阱会导致 HTTP/2 实际未生效，或被中间设备阻断：
- 确认只在
listen 443 ssl http2行启用，不在 80 端口加 http2（明文 h2c 浏览器不支持，且会引发协议错乱） - 检查 WAF、CDN 或 LB 是否终止 HTTPS 并重发为 HTTP/1.1 —— 此时后端 Nginx 收到的是 HTTP/1.x 请求，
http2配置完全无效 - 若使用 hosts 绑定测试发现 HTTP/2 突然生效，大概率是 DNS 解析路径中某层（如公共 DNS 或运营商劫持）干扰了 ALPN 握手，需对比不同网络环境下的
nghttp -v https://domain输出
启用日志定位具体失败环节
在 error_log 中打开调试级别，捕获 TLS 和 HTTP/2 协商细节：
- 临时添加
error_log /var/log/nginx/error.log debug;（注意磁盘空间） - 关注关键词：
ALPN protocols（是否列出 h2）、no ALPN negotiated（客户端不支持）、SSL_do_handshake() failed（握手异常）、client sent no stream（h2 帧解析失败） - 配合
access_log中的$server_protocol变量，确认实际处理协议：log_format http2 '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $server_protocol';
