Nginx中gzip与proxy_buffering需分工协同：gzip负责压缩减体积，proxy_buffering负责缓冲稳传输；开启gzip on、proxy_buffering on，并合理配置gzip_min_length、gzip_comp_level、proxy_buffer_size及proxy_buffers等参数，可显著提升文本资源加载速度与吞吐稳定性。
Linux 下 Nginx 配合 gzip 压缩优化代理缓冲区传输效率，核心不是“让 gzip 和 buffer 硬凑一起”，而是让两者各司其职、不互相拖累：gzip 负责减体积，proxy_buffering 负责稳传输，二者协同才能真正提升后端到客户端这一整段链路的响应质量与吞吐稳定性。
明确 gzip 和 proxy_buffering 的分工
gzip 是内容层压缩，在响应体生成后、发送前做文本压缩；proxy_buffering 是代理层缓冲，控制 Nginx 从上游（如 PHP-FPM 或后端服务）读取响应时是否暂存、如何分块转发。二者不在同一处理阶段，但配置不当会引发冲突：
- 若 proxy_buffering off，Nginx 边收边上发，gzip 压缩可能因流式输出不完整而失效或降级（尤其对 chunked 响应）
- 若 proxy_buffers 过小 + gzip_comp_level 过高，可能触发频繁内存分配或压缩超时
- gzip_vary on 必须配合 proxy_cache 或 CDN 使用，否则反向代理缓存易错判（比如把 gzip 版本缓存后返回给不支持的客户端）
关键配置组合建议
在 http 或 upstream-aware 的 server 块中，按以下逻辑设置：
- 启用并约束 gzip：gzip on; gzip_min_length 1000; gzip_comp_level 5; gzip_types text/plain text/css application/javascript application/json text/xml application/xml+rss image/svg+xml;
- 开启代理缓冲且留足空间：proxy_buffering on; proxy_buffer_size 128k; proxy_buffers 8 128k; proxy_busy_buffers_size 256k;
- 避免压缩干扰缓冲行为：确保 upstream 不主动设置 Content-Encoding: gzip（由 Nginx 统一压缩更可控）；禁用对已压缩资源的二次压缩（如不加 image/jpeg 到 gzip_types）
- 配合传输优化指令：tcp_nopush on; tcp_nodelay on; sendfile on; —— 这些能让压缩后的数据包更高效落网卡
验证是否真正生效
不能只看配置写了没，要逐层确认：
- 用 curl -I https://yoursite.com/test.js | grep "Content-Encoding"，看到 gzip 才说明压缩走通
- 检查响应头是否有 X-Accel-Buffering: no（表示 proxy_buffering 被绕过），正常应无此头
- 对比开启前后 TTFB 和完整 HTML 加载时间，重点观察大 JS/CSS 文件的下载耗时是否明显下降
- 监控 nginx worker 进程 CPU 使用率，若 gzip_comp_level 设为 9 后 CPU 持续 >70%，说明压缩成本已超过收益，应回调至 4–5
常见踩坑点
这些细节容易被忽略，却直接影响效果：
- gzip_types 里漏了 application/json 或 text/javascript，导致 API 响应和现代模块化 JS 未被压缩
- 在 location ~ \.php$ 块中重复写 gzip on，反而覆盖了 http 块的合理全局设置
- proxy_buffer_size 设得太小（如默认 4k），无法容纳带 gzip 头的响应首块，导致截断或 fallback 到无缓冲模式
- 用了 proxy_cache 但没配 proxy_cache_valid 200 10m，导致压缩后的内容被缓存但未设有效期，后续更新不生效
