设成256反而让Chrome加载变慢，因未同步调大http2_streams_index_size导致哈希冲突激增，ngx_http_v2_lookup_stream CPU占比飙升；且后端若为HTTP/1.1，256个流全挤在单连接上排队，放大队头阻塞。
直接调高 http2_max_concurrent_streams 不会提升实际并发性能，反而容易触发内存暴涨和 CPU 查找开销上升；它只是给单个 HTTP/2 连接设了个流数上限，真瓶颈往往在后端吞吐、哈希表大小或连接生命周期管理上。
为什么设成 256 反而让 Chrome 加载变慢
浏览器确实会尝试在一个连接里并行发 200+ 请求（比如画廊页加载高清图），但 Nginx 并不只靠这个值“放行”。若同时没调大 http2_streams_index_size，每个连接的流索引哈希表太小，就会频繁哈希冲突——ngx_http_v2_lookup_stream 函数 CPU 占比飙升，请求卡在查找阶段，页面反而更卡。
- 设
http2_max_concurrent_streams为 256 时，http2_streams_index_size至少得配成 128 或 256（必须是 2 的幂） - 每连接内存开销 ≈
http2_streams_index_size × 8字节；128 → 约 1 KB，1 万并发连接就多占 10 MB - Chrome DevTools 中看到多个请求共享同一
Connection ID且协议列为h2，才说明多路复用真在跑；否则只是“假 h2”
后端不支持 HTTP/2 时，调这个参数毫无意义
反向代理场景下，Nginx 能开 256 个流，不代表后端能接住。如果 upstream 是 HTTP/1.1 + keepalive，默认单连接只处理 1 个活跃请求——你开了 256 个流，结果全挤在 1 条后端连接上排队，等于把队头阻塞从客户端搬到了 Nginx 和后端之间。
- 确认上游是否支持 HTTP/2：检查其
SETTINGS_MAX_CONCURRENT_STREAMS，不匹配会被 RST_STREAM - 更稳的做法是配
proxy_http_version 1.1+upstream keepalive 32，让 Nginx 复用固定数量的后端连接 - 压测时观察
stub_status的Writing状态占比；持续高于 30%，说明后端响应慢，不是流数问题
该限制本质是防坏连接，不是扩容手段
设成 1000 看似“更宽松”，实则是放大单个恶意或缺陷客户端的杀伤力。HTTP/2 流不结束，Nginx 就得一直维护其缓冲区、窗口状态、优先级树——内存和锁竞争压力直线上升，worker 进程可能卡死。
- 默认 128 已覆盖绝大多数正常场景；电商详情页可试 192，但必须同步收紧
http2_idle_timeout 60s和http2_max_requests 1000 - 日志中搜
"max streams exceeded"或"stream not found"，能快速区分是客户端违规还是配置失当 - 用
perf top -p $(pgrep nginx)看ngx_http_v2_lookup_stream占比，超 15% 就该查哈希表大小
真正卡住的从来不是流数上限，而是流背后的状态维护成本、后端承接能力、以及连接是否及时释放。调 http2_max_concurrent_streams 前，先看 http2_streams_index_size 配没配对、upstream keepalive 有没有、stub_status 里 Writing 高不高——漏掉任意一项，调了也白调。
