Nginx对HTTP/2和HTTP/3的支持依赖底层架构深度适配：HTTP/2内置于SSL模块、需HTTPS及ALPN协商；HTTP/3基于QUIC（UDP）、需编译启用v3模块及QUIC后端，支持多协议共存于事件驱动模型，但受限于TLS强制、平台及配置约束。
Nginx 对 HTTP/2 和 HTTP/3 的支持不是简单地“打开开关”，而是依赖其底层架构设计与协议实现机制的深度适配。它既不是被动转发，也不是全盘重写协议栈，而是在保持自身事件驱动、多进程模型优势的前提下，分层接入新协议能力。
HTTP/2 支持基于 SSL 模块与连接复用扩展
Nginx 自 1.9.5 版本起将 HTTP/2 实现内置于 SSL 模块中，前提是启用 HTTPS（即必须配置 ssl）。它不单独解析 HTTP/2 帧，而是交由 OpenSSL（≥1.0.2）或 BoringSSL 在 TLS 握手完成后，通过 ALPN 协商确定协议版本。一旦协商为 h2，Nginx 就在已建立的 TLS 连接上启动二进制帧解析器，完成：
- 将客户端发来的 HEADERS+DATA 帧解包为内部 request 结构
- 利用已有 connection 复用机制，支持单连接多请求（stream multiplexing）
- 复用原有的 upstream 转发逻辑，对后端仍可走 HTTP/1.1 或 HTTP/2（需 upstream 显式支持）
- 头部压缩使用 HPACK，但动态表管理由 Nginx 内部轻量实现，不依赖外部库
HTTP/3 支持需 QUIC 协议栈与 UDP 事件处理重构
HTTP/3 不同于 HTTP/2——它不跑在 TCP 上，而是构建在 QUIC（基于 UDP）之上。Nginx 从 1.25.0 版本（2026 年 4 月发布）开始提供实验性支持，但要求：
- 编译时启用
--with-http_v3_module及 QUIC 后端（如 quiche 或 ngtcp2） - 监听指令分离：UDP 端口用于 QUIC 流量（
listen 443 quic reuseport），TCP 端口回退（listen 443 ssl http2） - QUIC 连接生命周期由 Nginx 自主管理：包括连接 ID 绑定、0-RTT 数据校验、丢包重传、连接迁移等，不再依赖内核 TCP 栈
- HTTP/3 层仅负责将 QUIC stream 上的 QPACK 编码帧还原为 HTTP 消息，再交由统一的请求处理管线（location 匹配、proxy_pass 等）
共用核心：事件驱动模型支撑多协议并存
Nginx 的 epoll/kqueue I/O 多路复用引擎天然适合处理异构协议流量。在实际部署中，一个 server 块可同时服务三类连接：
- TCP + TLS + HTTP/1.1（默认 fallback）
- TCP + TLS + HTTP/2（ALPN 协商成功后激活）
- UDP + QUIC + HTTP/3（独立 socket，独立连接状态机）
所有连接共享同一套 timer、buffer pool 和内存池管理，但协议解析、流控、加密上下文完全隔离。这种“一核多面”设计，让 Nginx 在不牺牲性能的前提下，平滑演进协议支持能力。
关键限制与现实约束
协议支持程度不仅取决于 Nginx 版本，还受制于运行环境：
- HTTP/2 必须搭配 TLS，纯明文 HTTP/2（h2c）仅限本地测试，Nginx 不推荐也不默认启用
- HTTP/3 当前不支持 Windows 平台；Linux 下需开启
net.ipv4.ip_unprivileged_port_start=0才能绑定非 root 用户的 UDP 443 - Alt-Svc 响应头是客户端发现 HTTP/3 的关键，Nginx 需手动添加
add_header Alt-Svc 'h3=":443"; ma=86400'; - WebSocket 在 HTTP/2 中受限（RFC 8441 定义了升级机制），而在 HTTP/3 中原生支持，但 Nginx 1.25 尚未实现 WebSocket over HTTP/3
