ALPN 是什么
ALPN（应用层协议协商，RFC 7301）让客户端在 TLS 握手阶段就告知自己支持的 HTTP 版本，服务端挑一个并在握手中确认，从而省掉一次额外的探测往返。HTTP/2 强制要求通过 ALPN 协商出 h2；HTTP/3 走 QUIC，用 h3 标识。整个过程对上层透明，所以配置缺失时往往没有任何报错，只是协议版本悄悄退回。
基本信息
| 标准 | RFC 7301 |
|---|---|
| 常见取值 | h2（HTTP/2）、http/1.1、h3（HTTP/3 经 QUIC） |
| 作用 | 在握手中确定应用层协议版本 |
| 启用方式 | Nginx 在 listen 上带 http2 参数，较新版本用 http2 on 指令 |
| 失败表现 | 协商不一致时回退到 http/1.1 或产生握手告警 |
| 中间设备 | 反向代理、负载均衡与 CDN 需正确透传协商结果 |
典型使用场景
- 启用 HTTP/2：升级后必须确认协商出 h2，否则多路复用等收益无从体现
- 排查「HTTP/2 没生效」：把命令行协商结果与浏览器表现对照
- 网关与 CDN 排障：客户端看到的协议版本与源站不一致时先查这里
- 灰度切换 HTTP/2 或 HTTP/3：按域名或 SNI 分批开启并观察协商情况
查看协商结果
查看协商结果
# 只声明 h2，观察服务端是否接受并回选
openssl s_client -connect example.com:443 -alpn h2 </dev/null 2>&1 | grep -i alpn
# 同时声明多个协议，观察最终选中哪一个
openssl s_client -connect example.com:443 -alpn 'h2,http/1.1' </dev/null 2>&1 | grep -i 'ALPN protocol'
# 从客户端侧确认实际使用的 HTTP 版本
curl -sI --http2 https://example.com | head -1观察点与含义
| 现象 | 含义 | 处置 |
|---|---|---|
| ALPN protocol: h2 | 协商成功升级到 HTTP/2 | 继续确认配置覆盖范围 |
| ALPN protocol: http/1.1 | 未选中 h2 | 检查服务端是否启用了 h2 支持 |
| No ALPN negotiated | 双方都没有进行协商 | 客户端或服务端一侧未提供 ALPN |
| 握手失败或告警 | 协议组合不被接受 | 核对 TLS 版本与套件要求 |
关闭 ALPN 或未配置会导致 HTTP/2 无法启用，浏览器会静默回退到 HTTP/1.1，性能优化随之失效。
协商失败通常是静默的：用户看不到报错，只会感觉变慢。把 ALPN 结果纳入例行巡检，比等故障上报更有效。
中间设备要单独验证：反向代理、负载均衡与 CDN 需要正确透传或重新发起协商，源站配置正确并不代表客户端能拿到 h2。