nginx缓冲区配置需按协议角色区分：http/1.x用client_header_buffer_size、large_client_header_buffers、client_body_buffer_size等；http/2调http2_max_field_size和http2_max_header_size；反向代理用proxy_buffering、proxy_buffer_size、proxy_buffers等；tcp/grpc等需proxy_receive_buffer_size、ssl_buffer_size。
调整 Nginx 中针对不同协议的缓冲区配置，关键在于区分 HTTP/1.x、HTTP/2 和代理场景下的实际生效参数——不是所有名字带“buffer”的指令都通用，更不能套用不存在的配置（比如 http2_recv_buffer_size 根本不存在）。核心原则是：按协议角色选参数，按真实瓶颈调数值。
HTTP/1.x 客户端请求缓冲区
这是处理浏览器或客户端直连 Nginx 时最基础的一组配置，直接影响能否成功接收请求头和请求体：
- client_header_buffer_size：设初始请求头缓冲大小，普通网站用 4k 足够；含长 Token、多段 Cookie 或前端埋点头的，建议 8k
- large_client_header_buffers：格式为 数量 大小（如 4 16k），单个请求头必须能放进其中一个 buffer；超限直接返回 414 或 400
- client_body_buffer_size：控制 POST/PUT 请求体缓存大小，API 场景推荐 16k～64k；大文件上传需同步调高 client_max_body_size
HTTP/2 连接的实际可调项
Nginx 的 HTTP/2 实现不暴露独立接收缓冲区指令。所谓“调优”应聚焦在帧解析与头部限制上：
- http2_max_field_size：单个 header 字段上限，默认 4k；若后端返回带超长自定义字段（如 JWT 声明），可增至 8k
- http2_max_header_size：整个请求头总长上限，默认 16k；微服务网关透传大量 header 时建议设为 32k
- client_max_body_size：虽属 HTTP/1.x 语境，但对 HTTP/2 的请求体仍完全生效，不可忽略
- 系统级参数如 net.core.rmem_max 才真正影响 TCP 层接收窗口，需配合调优
反向代理（proxy）场景缓冲区
当 Nginx 充当网关或负载均衡器时，它与后端（upstream）之间的缓冲行为由另一套参数控制，这对性能影响极大：
- proxy_buffering on/off：关闭后所有缓冲参数失效，响应边收边发，延迟低但吞吐弱；生产环境一般保持 on
- proxy_buffer_size：仅存响应头，4k 足够，不必随 body 缓冲一起放大
- proxy_buffers：存完整响应体，格式如 8 32k；静态资源可用 4 32k，动态 API 推荐 8 16k
- proxy_busy_buffers_size：控制发送中缓冲区上限，通常设为单 buffer 大小的 2 倍（如 64k）
- proxy_max_temp_file_size 0：设为 0 可禁用磁盘临时文件，强制全内存缓冲（需确保内存充足）
其他协议与底层影响因素
对于 TCP 流、gRPC 或 WebSocket 等非标准 HTTP 场景，还需注意：
- proxy_receive_buffer_size：影响内核 socket 接收缓冲，按带宽 × RTT 计算，例如 100Mbps + 100ms RTT 至少配 1.5MB
- ssl_buffer_size：TLS 记录层大小，调小（如 4k）利于降低首字节时间（TTFB），调大（如 16k）提升吞吐，需实测权衡
- 所有缓冲区总内存占用 ≈ 并发连接数 × 单连接平均缓冲用量，务必结合服务器内存总量规划，避免 OOM
