http2_max_requests 是 Nginx 中控制单个 HTTP/2 连接最大请求数的参数，达阈值后发送 GOAWAY 帧优雅关闭连接，用于平衡吞吐效率与连接健康；默认 1000，不推荐设为 0，需结合监控按业务场景调优。
HTTP/2 的连接复用机制依赖于长连接的稳定性，但过长的连接生命周期反而可能引发资源滞留、内存累积或上游异常堆积。http2_max_requests 正是控制单个 HTTP/2 连接最多处理多少请求后主动关闭的关键参数——它不是“越高越好”，而是要在吞吐效率与连接健康之间找平衡点。
理解 http2_max_requests 的作用边界
该指令仅对启用了 http2 的 HTTPS server 块生效，定义每个 TCP 连接上允许承载的最大 HTTP/2 流（requests）数量。达到阈值后，Nginx 会发送 GOAWAY 帧通知客户端终止当前连接，并在完成已发起流后优雅关闭。它不控制连接空闲时长（那是 keepalive_timeout 的职责），也不影响 TLS 会话复用（由 ssl_session_cache 管理）。
- 默认值为 1000，适用于多数中低流量场景
- 设为 0 表示不限制请求数量，仅靠超时或错误触发断连——生产环境不推荐
- 该值只约束 Nginx 与客户端之间的连接，不影响 upstream 的连接行为
什么情况下需要调低 http2_max_requests
当观察到以下现象时，说明连接“太老”，建议主动缩短其生命周期：
- 内存占用随连接持续时间增长明显（尤其在高并发下，每个连接维护 HPACK 状态、流窗口、优先级树等上下文）
- 客户端出现偶发性“连接重置”或“ERR_HTTP2_PROTOCOL_ERROR”，且集中在连接建立较久之后
- 上游服务存在连接泄漏（如未正确复用 HTTP/1.1 keepalive），导致 Nginx 长连接持续向后端转发新请求，加剧后端连接池压力
- 灰度发布或滚动更新期间，旧连接仍持续复用，延迟新配置或证书变更的生效
什么情况下可以适当提高 http2_max_requests
提升该值有助于减少连接重建开销（TLS 握手 + TCP 三次握手 + ALPN 协商），适合以下场景：
- 客户端稳定、网络质量好（如内网 App 或企业浏览器），连接极少异常中断
- 静态资源占比高、请求轻量（如大量小图标、字体、JS/CSS），单连接可高效承载数百请求
- 已启用
ssl_session_cache shared:SSL:10m和ssl_session_timeout 4h，TLS 层复用充分 - 配合
keepalive_timeout 60s使用，确保连接既不过早断开，也不无限延续
推荐调优策略与典型配置
没有通用最优值，需结合监控数据动态调整。建议从默认值起步，逐步观测：
- 使用
nginx -V 2>&1 | grep -o with-http_v2_module确认模块已编译 - 开启连接级日志辅助分析：
log_format http2 '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http2" $request_length $request_time $upstream_response_time'; - 在 server 块中设置合理上限，例如：http2_max_requests 500;（比默认略保守，利于快速释放异常连接）
- 若业务含大量短生命周期 API 调用（如移动端心跳、埋点），可降至 200–300；若主打 CDN 分发静态内容，可尝试 1000–2000
