HTTP/2未取消KeepAlive，而是将其从应用层头协商下沉为TCP连接池管理与协议内建复用；Nginx中keepalive_timeout仍关键（建议60–120s），keepalive_requests对h2失效，后端需显式配置upstream keepalive并强制proxy_http_version 2.0。
HTTP/2 本身不依赖传统 HTTP/1.x 的 Connection: keep-alive 头，但 Nginx 中的 KeepAlive 机制并未消失，而是从“显式协商”转向“隐式保障”，重点转移到连接复用效率和底层 TCP 生命周期管理上。
HTTP/2 下客户端与 Nginx 的 KeepAlive 行为变化
HTTP/1.1 的 Keep-Alive 是靠响应头 Connection: keep-alive 和 Keep-Alive: timeout=60, max=100 显式告知客户端；而 HTTP/2 协议默认启用长连接，且禁止使用 Connection、Keep-Alive、Upgrade 等 1.x 特有头字段。Nginx 在启用 http2 后会自动忽略并清理这些头。
- keepalive_timeout 依然关键：它不再影响协议协商，而是控制空闲 TCP 连接的保活时长。建议设为 60s–120s，与主流浏览器（如 Chrome、Firefox）的默认空闲策略对齐，避免过早断连。
- keepalive_requests 不再生效：HTTP/2 的多路复用天然支持单连接承载无限请求（受限于流数量上限），该参数对 h2 连接无实际约束作用，可保留但无需调优。
-
客户端无需发送 Connection: keep-alive：只要 TLS 握手成功并协商出 h2，连接即默认复用；浏览器开发者工具 Network 面板中 Protocol 列显示
h2即代表已进入多路复用状态。
Nginx 与后端之间的 KeepAlive 必须显式配置
仅前端支持 HTTP/2 不够——若 Nginx 到后端仍走 HTTP/1.1 短连接，多路复用优势就卡在网关层，无法传导至服务集群。
-
必须启用 upstream keepalive：在
upstream块中配置keepalive N（例如keepalive 32），维持与每个后端服务器的空闲连接池。 -
强制升级到 HTTP/2 上游协议：需满足三个条件：
–proxy_pass https://backend（必须是 HTTPS）
–proxy_http_version 2.0
– 清理干扰头：proxy_set_header Connection ''和proxy_set_header Upgrade '' - 避免 keepalive 数值失衡：设为 16–100 之间较稳妥；过小（如 2）导致频繁建连，过大（如 500）可能压垮后端连接数限制。
验证是否真正发挥 KeepAlive + HTTP/2 效能
不能只看响应状态码或协议名，要确认“单连接多流”是否落地。
- 用
curl -I --http2 https://your-domain.com检查是否协商成功； - 浏览器 Network 面板开启 Protocol 列，观察多个资源是否共用同一 connection 并均标记为
h2； - 后端日志或 Wireshark 抓包，确认同一 TCP 连接 ID 上出现交错的
HEADERS+DATA帧，而非每个请求新建连接。
本质上，HTTP/2 没有取消 KeepAlive，而是把它的实现从应用层头协商，下沉为连接池管理与协议内建复用。配置重心也从“要不要保持”转向“如何高效复用”。
