http2_max_concurrent_streams控制单个HTTP/2连接最大并发流数，默认128，影响浏览器并行请求数量与服务器资源占用，值过低导致加载卡顿，过高易引发内存和CPU过载。
这个参数直接控制每个 HTTP/2 连接最多能同时打开多少个流（即并发请求），设得太低会限制多路复用能力，设得太高则可能让单个连接过度占用内存和 CPU。它不是全局上限，而是按连接独立生效的硬性限制。
它到底影响什么？
HTTP/2 的核心优势是“一个连接跑多个请求”，http2_max_concurrent_streams 就是这个“多个”的上限值。默认是 128，意味着一个客户端连上来，最多同时发 128 个请求（比如加载 128 张图、JS、CSS）。超过这个数的请求会被客户端排队或拒绝，不走网络，只在浏览器内部等待。
- 值太小（如设成 32）：大图页或 SPA 页面容易卡顿，浏览器明明想并行加载，却被强制串行，失去 HTTP/2 意义
- 值太大（如设成 1000）：单个恶意或异常连接就能创建大量流，消耗服务器内存（每个流需维护缓冲区、状态结构）、增加锁竞争和调度开销，尤其在高并发场景下易引发响应延迟上升
怎么定一个合理值？
别照搬文档默认值。先看你的典型业务场景：
Audio Upload Aioz Stream Free
下载
基于 AIOZ Stream API 的免费音频上传技能，通过三步流程（Create → Upload Part → Complete）将本地音频文件上传至 AIOZ 流媒体平台。支持默认快速上传方式，使用默认编码配置，上传完成后返回 HLS 流媒体播放链接。使用 API Key (stream-publ...)进行认证。
- 普通内容站（文章+少量图）：64–128 已足够，多数连接活跃流数在 5–20 之间
- 大图/电商详情页（单页 50+ 图片）：建议 192–256，配合前端懒加载和自然 DOM 加载节奏，避免 JS 批量 fetch 塞满流
- API 网关类服务（长轮询、SSE、gRPC-Web）：需结合超时与 keepalive 控制连接生命周期，值可设为 128，但必须配 http2_idle_timeout 和 http2_max_requests 防止连接长期滞留
调优时必须配合的关键项
单独改这个参数效果有限，甚至有害。要一起调整：
- http2_idle_timeout：设为 3m–5m，及时关闭空闲连接，释放流槽位
- http2_max_requests：设为 1000–5000，防止单连接无限复用导致内存缓慢泄漏（尤其 Nginx 旧版本）
- worker_connections：确保总并发连接数 × 平均活跃流数 ≤ worker_connections × worker_processes，否则新连接会被拒绝
- upstream keepalive：后端用 HTTP/1.1 + keepalive 复用连接，避免每条 HTTP/2 流都新建一条后端连接
验证是否调对了
改完别只看“能不能用”，要看真实负载下的表现：
- 用 stub_status 或 vts 模块观察 Active connections 和 Writing 状态占比，若 Writing 长期高于 30%，说明流处理不过来，可能需要降值或查后端瓶颈
- 压测时用 nginx -T 查实际生效配置，再用 curl -I --http2 -v https://yoursite.com 确认协议协商成功
- Chrome DevTools → Network → 右键表头勾选 Protocol 和 Connection ID，确认同 Connection ID 下确实有多个 h2 请求并行，且无大量 pending
