http2_max_concurrent_streams仅设单连接理论流上限，不能自动提升并发能力；需按业务场景（如图文页64–128、高清图页192–256）匹配请求密度，并同步调优http2_streams_index_size及上游承载力。
直接调高 http2_max_concurrent_streams 并不能自动提升并发处理能力，它只是为每个 HTTP/2 连接设定了理论上的最大并发流数。真正发挥多路复用价值，需结合业务特征、内存开销和上游承载力做协同调整。
按业务场景选合理值
默认 128 对多数站点已够用，但不同页面加载模式差异大，需匹配真实请求密度：
- 普通图文页或轻量 SPA：64–128 即可。活跃流通常在 5–20 之间，设太高反而浪费资源
- 高清图密集页（电商详情、摄影画廊）：可设为 192–256。前提是前端自然加载节奏明显（如 DOM 触发而非 JS 批量 fetch），且后端能稳定承接
- API 网关或 JSON 接口服务：建议 64–100。后端连接池常较紧，过高易引发排队延迟
- 含 SSE 或长轮询的实时页面：应调低至 16–32，避免流长期占位，影响新请求接入
必须同步调整 http2\_streams\_index\_size
这个参数控制每个连接中流索引哈希表的大小，直接影响查找效率和内存占用——它不决定流数，但决定流多了之后“找得快不快”：
Audio Upload Aioz Stream Free
下载
基于 AIOZ Stream API 的免费音频上传技能，通过三步流程（Create → Upload Part → Complete）将本地音频文件上传至 AIOZ 流媒体平台。支持默认快速上传方式，使用默认编码配置，上传完成后返回 HLS 流媒体播放链接。使用 API Key (stream-publ...)进行认证。
- 若
http2_max_concurrent_streams设为 256，http2_streams_index_size建议设为 128 或 256（必须是 2 的幂） - 设太小（如仍用默认 32）→ 哈希冲突增多 →
ngx_http_v2_lookup_streamCPU 占比异常升高 - 设太大 → 空桶浪费内存。估算：每连接约增加
index_size × 8 字节，1 万并发连接时，从 32 升到 256 就多占约 17 MB
别忽略上游服务的实际吞吐瓶颈
Nginx 能发 256 个流，不代表后端能同时处理 256 个请求。尤其反向代理场景下：
- 上游若用 HTTP/1.1 + keepalive，单连接通常只支持 1 个活跃请求 → 提高 streams 值无意义
- 上游若支持 HTTP/2（如 gRPC 服务），需确认其
SETTINGS_MAX_CONCURRENT_STREAMS是否匹配，否则会被对端主动 RST_STREAM - PHP-FPM 只有 32 个 worker？那
http2_max_concurrent_streams超过 40 就大概率触发上游排队，延迟反而上升
验证是否真生效，而非“假开启”
改完配置不等于优化落地，务必交叉验证：
- Chrome DevTools → Network → 右键表头勾选 “Protocol” 和 “Connection ID”，确认多个请求共享同一 Connection ID 且协议列为
h2 - 日志中加
$http2变量，抽样检查高峰时段是否真走 HTTP/2 - 观察
upstream_addr日志：若单个 client IP 频繁新建 upstream 连接，说明流被快速耗尽，http2_max_concurrent_streams可能设得太小 - 用
ss -s对比 ESTAB 连接数与nginx_stub_status中 Active connections，若前者远大于后者，说明大量连接未成功协商 HTTP/2
