gzip_buffers决定单个响应能否全程内存压缩，不提升并发数但保障高并发稳定性；它仅存压缩后数据块，不参与计算，超限则回退磁盘临时文件，配置需匹配典型压缩体积。
gzip_buffers 不直接“承载”并发任务，而是为每个启用压缩的响应分配独立的内存空间来暂存压缩后的字节流。它的作用不是提升并发数，而是决定单个响应能否全程在内存中完成压缩输出——这对高并发场景下的稳定性至关重要。
它管什么、不管什么
gzip_buffers 只存放已压缩完成的数据块，不是原始响应体，也不参与压缩计算过程。一个 80KB 的 HTML 经 gzip 压缩成 22KB，这 22KB 就会被切分成若干块（如 5 × 4KB），放进 gzip_buffers 分配的内存页里。
- 默认配置 gzip_buffers 32 4k = 128KB 总内存，专供压缩结果使用
- 若单次压缩后数据 ≤128KB，全部走内存，无磁盘 I/O
- 若超限（比如压缩后 140KB），Nginx 尝试申请第 33 块失败，就会 fallback 到 gzip_temp_path 写临时文件
- 一旦磁盘满、权限异常或 I/O 拥塞，极易触发连接中断或 500 错误
高并发下真正影响承载能力的关键点
每条启用 gzip 的连接都会独占一组缓冲区。1000 并发 × 128KB = 至少 128MB 纯压缩缓冲内存。但问题往往不在总量，而在碎片与错配：
- proxy_buffer_size 过小（如仍用默认 4k）：首块响应头+部分 body 就填满，触发多次 flush → 每次 flush 都要单独申请 gzip_buffers 块 → 缓冲碎片爆炸
- gzip_min_length 设太高（如设 1k，但大量 JSON 实际 900B）：压缩流程根本没触发，缓冲区全闲置，而小响应堆积反而拖慢连接复用
- 盲目堆数量（如 gzip_buffers 128 4k）：需连续 512KB 虚拟内存页，高并发易触发 ENOMEM，得不偿失
按业务类型选配更有效的组合
目标不是“越大越好”，而是让单块大小贴近典型压缩后体积，减少申请次数和页对齐开销：
- JSON API 服务（压缩后多为 8–15KB）：保持 32 4k 即可；若平均超 16KB，改用 16 8k
- 动态 HTML 页面（含内联 JS/CSS，压缩后常达 50–100KB）：推荐 8 16k 或 16 8k，避免申请上百小块
- 静态资源代理（启用了 gzip_static on）：该参数完全无效，压缩由 .gz 文件提供，无需调优
验证是否够用，靠日志和实测
别凭感觉调参，用真实流量说话：
- 在 nginx.conf 加：error_log /var/log/nginx/error.log notice;
- 压测时搜日志关键词：gzip buffer too small 或 gzip temporary file write error
- 用 curl 快速估算：curl -I -H 'Accept-Encoding: gzip' http://host/path，看 Content-Length 响应头（即压缩后大小）
- 例如返回 Content-Length: 72450 ≈ 70KB → 至少需 18 块 4KB，但建议留余量，选 16 8k（128KB） 更稳妥
