http2_max_concurrent_streams 控制单个http/2连接最大并发流数，默认128，需结合业务类型（图文页64–128、图密集页192–256、api网关64–100）、上游能力及配套参数（http2_idle_timeout、http2_max_requests、upstream keepalive）协同调优，避免内存/cpu过载或流耗尽导致连接重建。
直接设一个固定值不能解决资源分布问题，http2_max_concurrent_streams 控制的是“单连接内最多跑几个请求”，它本身不调度连接、不分配资源，只划清每条连接的流上限。真正影响并发连接资源分布的，是它与上游处理能力、Nginx 工作模型、以及配套参数的协同关系。
看业务请求密度，定基础取值锚点
不同页面加载行为决定流的实际压力：
- 普通图文页（文章+图标/字体）：64～128 足够，浏览器平均活跃流通常在 5–20 之间，留足余量即可
- 高清图密集页（电商详情、画廊）：192～256 更稳妥，避免浏览器因流耗尽而新建连接，但需确认 worker_connections ≥ 16384
- API 网关或长轮询服务：64～100 更安全，后端连接池常较紧（如 PHP-FPM 只有 32 个 worker），超 40 就易触发上游排队
必须同步调优的关键配套项
单独改这个值容易失衡，以下三项要一起配：
- http2_idle_timeout：设为 3m～5m，及时释放空闲连接，避免大量“半死”连接占着流槽位不放
- http2_max_requests：设为 1000～5000，防止单连接长期复用导致内存缓慢增长（尤其旧版 Nginx）
-
upstream keepalive：后端用 HTTP/1.1 + keepalive 复用连接，比如
keepalive 32，避免每个 HTTP/2 流都新建一条后端连接
控制流索引开销，防止 CPU 暗涨
每个连接都要维护一张流哈希表，大小由 http2_streams_index_size 决定（必须是 2 的幂）：
- 若
http2_max_concurrent_streams设为 256，建议http2_streams_index_size设为 128 或 256 - 设太小（如仍用默认 32）→ 哈希冲突多 →
ngx_http_v2_lookup_streamCPU 占比异常升高 - 设太大（如 1024）→ 空桶浪费内存，万级连接时多占几十 MB
验证是否真起作用，而不是假生效
配置 reload 后，别只信日志，要交叉确认：
- Chrome DevTools → Network → 勾选 “Protocol” 和 “Connection ID”，看多个请求是否共用同一 ID 且协议列为
h2 - 查 upstream 日志中同一 client IP 是否频繁新建 upstream 连接——若是，说明流被快速用尽，值可能偏小
- 用
ss -s对比 ESTAB 连接数和 stub_status 中 Active connections，若前者远大于后者，说明很多连接没走 HTTP/2（可能是 ALPN 协商失败）
