http2_recv_buffer_size是每个worker为每个http/2连接分配的初始接收缓冲区大小，影响帧接收完整性、hpack解压连续性及多路复用头部暂存；应据header大小、server push需求等场景设为256k–1m，须配合http2_recv_timeout并验证rcv_space与协议行为。
在高并发 HTTP/2 场景下，http2_recv_buffer_size 的默认值（256k）常成为吞吐瓶颈——尤其当客户端批量推送大 Header、或服务端需快速解析多路复用流时，缓冲区不足会触发频繁的系统调用和内存拷贝，反而拖慢接收效率。
理解 http2_recv_buffer_size 的实际作用
这个参数不是“越大越好”的通用缓冲池，而是每个 worker 进程为每个 HTTP/2 连接分配的**初始接收缓冲区大小**。它直接影响：
- 能否一次性收完一个完整帧（Frame）或连续小帧序列，避免分多次 read() 系统调用
- 是否需要立即触发 HPACK 解压逻辑（Header 帧压缩后仍需解压，缓冲区太小会导致解压中断重试）
- 在多路复用中，多个 Stream 的头部帧交错到达时，是否有足够空间暂存待调度的数据
根据典型流量模式调整建议
不建议盲目调大。应结合真实请求特征判断：
- 若多数请求带大 Cookie、JWT Token 或自定义长 Header（如
Authorization: Bearer eyJ...超 4KB），可设为512k或1m - 若使用 Server Push 主动推送资源（如 CSS+JS 预加载），且推送内容头部较复杂，建议不低于
384k - 纯 API 场景（Header 简洁、Body 小）、无 Push，保持默认
256k即可，增大反而浪费内存 - 注意：该值不能超过系统 socket 接收缓冲区上限（
net.core.rmem_max），否则启动报错
配合 http2_recv_timeout 使用更有效
单独调大缓冲区不解决延迟问题，必须与超时协同：
-
http2_recv_timeout 15s（比默认 30s 更激进）可更快释放卡在半帧接收中的连接 - 当缓冲区填满但未构成完整帧时，Nginx 会等待超时才关闭连接；缩短 timeout 可减少“假阻塞”连接堆积
- 观察
nginx -t日志中是否有http2 frame error或recv() failed，是调整这两项的关键信号
验证是否生效的实操方法
改配置后别只看启动成功，要确认运行时行为：
- 用
ss -i查看活跃 HTTP/2 连接的rcv_space是否接近你设置的值（需开启net.ipv4.tcp_rmem自动调优） - 在 Chrome DevTools → Network → 右键表头 → 勾选
Protocol和Connection ID，对比相同 Connection ID 下不同请求的 Header 大小与响应延迟变化 - 用
curl --http2 -v https://yoursite.com观察是否出现* Connection state changed (HTTP/2 confirmed)且无header overflow类警告
