调高http2_max_concurrent_streams仅设理论流上限，需结合后端承载力、内存开销及请求模式协同调整；默认128适配多数场景，api服务建议64～100，高清图页可设200～256并匹配http2_streams_index_size，sse/ws页面须≤32。

调高 http2_max_concurrent_streams 不等于提升并发性能，它只是放宽单个 HTTP/2 连接内允许并行的请求数上限。真正发挥多路复用价值，得看后端承载力、内存开销和实际请求模式是否匹配。

按业务类型选合理值

默认 128 适合大多数网站，但不同场景需差异化设置：

• API 服务（JSON 接口为主）：设为 64～100。后端通常是 Go/Java，连接池偏紧，过高会导致上游线程排队，延迟反升
• 高清图/静态资源密集页（电商详情、画廊）：可设为 200～256，前提是后端是 CDN 或对象存储，且 worker_connections ≥ 16384
• 含 SSE 或 WebSocket 升级的页面：必须 ≤ 32。这类长连接本身占流，留足余量防阻塞
• 轻量图文或小图标/字体多的页面：64 足够，还能降低每连接内存压力

必须同步调优 http2_streams_index_size

这个参数控制每个连接里流索引哈希表的大小，直接影响查找效率和内存占用。它不决定流数，但流数提了，它不跟上就会出问题：

Upload audio to AIOZ Stream

快速上传音频至 AIOZ Stream API。支持默认或自定义编码配置创建音频对象，上传文件并完成处理后返回音频链接。

下载

• 若 http2_max_concurrent_streams 设为 256，http2_streams_index_size 建议设为 128 或 256（必须是 2 的幂）
• 设太小（如仍用默认 32）→ 哈希冲突增多 → ngx_http_v2_lookup_stream CPU 占比异常升高
• 设太大（如 1024）→ 空桶浪费内存 → 1 万并发连接多占约 80 MB，不划算

检查上游能否真正承接

Nginx 发出 256 个流，不等于后端能同时处理 256 个请求。关键要看上游协议与连接模型：

• 上游用 HTTP/1.1 + keepalive：单连接通常只跑 1 个活跃请求，靠连接池复用 → 此时提高 streams 值基本无效
• 上游支持 HTTP/2（如 gRPC）：需确认其 SETTINGS_MAX_CONCURRENT_STREAMS 是否匹配，否则会被对端主动 RST_STREAM
• PHP-FPM 只有 32 个 worker？那 streams 超过 40 就大概率触发排队，建议搭配 upstream keepalive 32 和 proxy_http_version 1.1 更稳

验证是否真生效

改完配置别急着上线，先交叉验证是否真的走通 HTTP/2 多路复用：

• Chrome DevTools → Network → 右键表头勾选 “Protocol” 和 “Connection ID”，确认多个资源共用同一 Connection ID 且 Protocol 为 h2
• 日志加字段：log_format http2 '$http2 $request_length $upstream_addr';，抽样看 $http2 是否为 “h2”
• 用 curl -I --http2 https://yoursite.com 检查响应头是否为 HTTP/2 200
• 观察 upstream_addr 日志：同一 client IP 是否频繁新建 upstream 连接？若是，说明流被快速耗尽，streams 值可能偏低