nginx 的 http/2 兼容性由编译模块、ssl/tls 协商机制和 listen 指令显式声明共同决定，worker process 仅调度转发已协商好的协议连接，不参与 alpn 协商或协议判断。
Nginx 的 worker process 本身不直接决定协议兼容性，它只是执行配置好的协议处理逻辑。真正的 HTTP/2 兼容性由三部分协同决定：编译模块、SSL/TLS 协商机制、以及 listen 指令的显式声明。worker process 在其中的角色是调度和转发，不是协议判断主体。
worker process 不解析 ALPN 或协商协议版本
ALPN（Application-Layer Protocol Negotiation）是在 TLS 握手阶段由 OpenSSL 完成的，发生在 TCP 连接建立之后、worker 接收请求之前。worker process 收到的已经是完成 TLS 握手且已确定应用层协议（h2 或 http/1.1）的连接。它只负责按既定协议栈处理帧（如解析 HTTP/2 的 HEADERS/DATA 帧）或报文（HTTP/1.1 的文本行）。
协议分支在连接初始化时就已确定
当客户端发起 TLS 握手并携带 ALPN 扩展（如 h2,http/1.1），OpenSSL 根据服务端支持列表（由 ssl_protocols + 编译能力决定）选择协议，并将结果透传给 Nginx 内核。此时：
- 若协商成功为
h2，worker 启动 HTTP/2 连接状态机，启用流控制、HPACK 解码等； - 若协商失败或客户端不支持 ALPN（如 OpenSSL
影响 worker 行为的关键配置不在进程级，而在 server 块内
以下配置直接决定 worker 处理哪个协议，且必须写在具体 server 块中：
- listen 443 ssl http2; —— 缺少 http2 关键字，即使 OpenSSL 支持 h2，worker 也不会启用 HTTP/2 状态机；
- ssl_protocols TLSv1.2 TLSv1.3; —— 若写成 TLSv1.1，现代客户端可能拒绝协商 h2（因 TLS 1.1 不被 HTTP/2 规范推荐）；
- ssl_ciphers 中若含 RC4 或 3DES，会触发协议降级，worker 最终只能走 HTTP/1.1。
worker_connections 与协议兼容无直接关系，但影响并发表现
HTTP/2 的多路复用大幅降低连接数需求，相同 worker_connections 值下可支撑更多并发流。但这属于性能适配，不改变协议协商结果。例如：
- 设 worker_connections 1024;，HTTP/1.1 下最多 1024 个并发连接；
- 同样配置下，HTTP/2 可承载远超 1024 个并发请求（因多路复用），但 worker 仍只管理这 1024 个底层 TCP 连接。
不复杂但容易忽略
