用代理IP 打开同样一个站点，速度有时快有时慢；抓包一看协议版本，h2 变成了 http1.1。这一步切换不是在应用层发生的，而是 TLS 握手时由 ALPN 协商出来的——而代理IP 链路两段连接各协商一次，中间任何一跳把 ALPN 标记”吃”掉，回退就发生了。
ALPN 是什么，在 TLS 握手的哪一步出现
ALPN 全称 Application-Layer Protocol Negotiation，是 TLS 1.2 之后引入的扩展，作用是在加密通道建立前把”接下来跑什么应用层协议”协商清楚。客户端在 ClientHello 里通过 extension 列出自己支持的应用层协议（h2、http/1.1），服务端在 ServerHello 里挑选一个写回来，两端按结果建立对应协议。
对浏览器和 HTTP 客户端而言，ALPN 协商结果直接决定后面是 HTTP/2 多路复用还是 HTTP/1.1 短连接。同一台服务、同一个客户端，ALPN 协商出 h2 走 HTTP/2，并发复用、头压缩都开起来；协商出 http/1.1 则每请求独立连接，性能差距可以拉到一个数量级。
走到代理IP 链路时，ALPN 协商在两段连接里各做一次：本机到代理一段、代理到目标站一段。客户端只看到自己这一段的结果，目标站只看到代理那一段的结果，中间有没有透传，两边都不知道。
| 代理类型 | ALPN 透传 | 协商结果 | 业务表现 |
|---|---|---|---|
| 透明转发型 | 原样转交 | 与直连一致 | h2 红利保留 |
| 隧道重建型 | 两段独立协商 | 可能不同 | 断点回退 |
| 中间设备掐 ALPN | 扩展被丢弃 | 回退到 http/1.1 | 并发性能掉档 |
怎么判断是不是 ALPN 在作怪
最直接的办法是抓包看 ClientHello 的 extension 列表里有没有 supported_application_layer_protocol，以及 ServerHello 里服务端回了哪个协议。如果客户端支持 h2、ServerHello 也回了 h2，那就是 h2；如果 ServerHello 根本没列协议扩展，那就默认走 http/1.1。代理IP 链路抓包要分别看两段，本机抓包看到的是本机到代理的协商，目标站侧抓包看到的是代理到目标站的协商；两段协商结果一致，h2 才能真正跑起来。
另一种快速验证是用 curl 加 --http2 强制 h2，看走代理IP 后响应头里的协议标记。如果服务端支持 h2 但实际回的是 http/1.1，问题基本就在代理链路——八成是中间设备不识别 ALPN 扩展被整体吞掉，协商阶段直接跳过，落到默认协议上。
排查方向：先确认直连是 h2，排除服务端问题；再确认本机到代理的协商是 h2，排除第一段；最后确认代理到目标站也是 h2，排除第二段。哪一段不一致，回退就发生在那一段的代理边界上。
ALPN 是 TLS 握手里最不起眼的一步，但代理IP 链路两段都要走一遍——任何一跳把它”吃”掉，HTTP/2 的红利就丢了。