gzip_buffers决定压缩后数据的内存切块方式,默认32 4k即分配32个4kb缓冲区共128kb,仅存压缩后数据;需据实际响应体大小(如api建议16 8k)、配合gzip_min_length及proxy_buffering调优,避免溢出至磁盘临时文件。

gzip_buffers 决定了压缩内容的内存切块方式
nginx 默认用 gzip_buffers 32 4k(或旧版本为 4 4k),意思是:每次压缩响应时,预分配 32 块、每块 4KB 的内存缓冲区。这些缓冲区只用于存放压缩后的数据,不是原始内容——原始响应体走的是 proxy_buffer 或 client_body_buffer_size 那套逻辑。
高压下溢出,往往不是因为“压缩太慢”,而是因为单次响应压缩后体积远超预期,导致需要更多缓冲块;而 nginx 在申请不到足够连续块时会 fallback 到临时文件(gzip_temp_path),但若磁盘满或权限不对,就直接 500 或连接中断。
- 若你服务大量 JSON API(平均压缩后 8–12KB),
gzip_buffers 32 4k够用;但若返回长 HTML(含内联 JS/CSS,压缩后常达 64KB+),建议改用gzip_buffers 16 8k或8 16k - 不要盲目堆数量,比如
gzip_buffers 128 4k看似更“宽裕”,实则浪费内存——每块都按页对齐,128×4KB = 512KB 连续虚拟内存,高并发时易触发ENOMEM - 检查实际使用量:加
error_log /var/log/nginx/error.log notice;,压力测试时搜gzip buffer too small或gzip temporary file write error
gzip_buffers 和 gzip_min_length 要配对调优
单独调大 gzip_buffers 没用,如果响应体小于 gzip_min_length,压根不进压缩流水线。常见错误是设了 gzip_min_length 1k 却返回大量 900B 的 JSON,结果缓冲区完全闲置,而小响应堆积反而加剧连接延迟。
- API 场景建议设
gzip_min_length 512,因为现代 JSON 响应即使空字段也常超 500B,压缩后收益明显 - 静态资源(CSS/JS)通常远大于 1k,可保持默认;但若用了
gzip_static on,注意它绕过gzip_buffers,直接读取 .gz 文件,此时该参数无效 - 用
curl -I -H 'Accept-Encoding: gzip' http://yoursite/api/test配合Content-Length响应头,手动估算压缩后大小,再反推需要多少缓冲块
避免 gzip_buffers 与 proxy_buffering 冲突
当启用 proxy_buffering on(比如 Nginx 作反向代理),响应先写入 proxy_buffers,再交给 gzip 流水线。如果 proxy_buffer_size 太小(如仍用默认 4k),首块响应头+部分 body 就可能填满,触发 flush,导致 gzip 流被切成多段——每段都要独立申请 gzip_buffers,碎片化加剧。
- 确保
proxy_buffer_size≥ 最大响应头长度(一般4k够,但带 JWT 或长 Cookie 时需8k) -
proxy_buffers总容量应 ≥ 单次典型响应体未压缩前大小,否则频繁刷 buffer,gzip 压缩效率下降且内存抖动 - 若后端稳定返回小响应(如
204 No Content),可关掉proxy_buffering,让流式直传,避开两层缓冲叠加
真正危险的是 gzip_temp_path 不可控
当 gzip_buffers 耗尽,nginx 会把剩余压缩数据写入 gzip_temp_path(默认 /usr/local/nginx/proxy_temp)。这个路径若落在系统盘、没配磁盘配额、或 SELinux 限制写入,高压下就会卡死 worker 进程。
- 显式配置
gzip_temp_path /var/tmp/nginx/gzip levels=1:2;,并确保目录存在、属主为 nginx 用户、有足够空间 - 加监控:
df -h /var/tmp+find /var/tmp/nginx/gzip -name "*gz" -mmin -5 | wc -l,看是否高频生成临时文件 - 最稳妥做法:压测时用
strace -p $(pgrep nginx) -e trace=write,openat抓到实际写入的临时文件路径,确认是否真走到磁盘
缓冲区不是越大越好,关键在匹配真实响应分布。上线前务必用真实 payload 压测,而不是只看配置数值。











