启用gzip压缩是提升nginx吞吐能力最简单见效的手段，可减少html/css/js/json等文本资源60%~75%体积，需配置gzip on、gzip_types、gzip_min_length 1k、gzip_comp_level 6及gzip_vary on，并配合keepalive长连接复用以最大化收益。
直接压缩文本资源，是提升 Nginx 吞吐能力最简单、见效最快的手段之一。它不增加硬件投入，却能显著降低带宽占用、减少传输时间、缓解后端压力——相当于让同一条公路跑更多车。
启用 Gzip 并精准控制压缩范围
不是所有文件都值得压缩。图片、视频、字体等二进制文件本身已高度压缩，再压反而浪费 CPU 且无收益。重点应放在 HTML、CSS、JS、JSON 等纯文本类资源上。
- 必须开启
gzip on，并显式声明要压缩的 MIME 类型，尤其别漏掉application/json（现代 API 响应主力） - 设置
gzip_min_length 1k：避免对极小文件（如空响应、tiny SVG）压缩，防止得不偿失 - 推荐
gzip_comp_level 6：在压缩率（约 70% 减少）和 CPU 开销之间取得良好平衡；高于 7 级提升有限，但 CPU 消耗明显上升 - 加上
gzip_vary on：确保代理或 CDN 能正确缓存压缩与未压缩两个版本，避免内容错乱
配合 KeepAlive 复用连接，放大压缩收益
压缩减的是“单次传输体积”，而 KeepAlive 减的是“每次传输前后的握手开销”。两者叠加，才能把吞吐潜力真正释放出来。
- 客户端到 Nginx：设
keepalive_timeout 65（略大于浏览器默认值），keepalive_requests 10000，支持高并发复用 - Nginx 到后端：这是常被忽略的关键点。必须在
upstream块中配置keepalive 32（或更高），否则 Nginx 默认用短连接，压缩省下的带宽又被频繁建连吃掉了 - 若后端是 Node.js/Python 等语言，还需确认其 HTTP 客户端也开启了 KeepAlive，否则上游长连接形同虚设
避免压缩干扰缓存与 CDN
压缩本身不改变内容语义，但会影响缓存策略。若处理不当，可能造成缓存失效或重复压缩。
- 静态资源（JS/CSS/图片）建议由浏览器或 CDN 缓存，Nginx 不参与压缩——这类文件通常已由构建工具预压缩（如 terser、cssnano）
- 动态响应（API、模板渲染页）才由 Nginx 实时压缩，此时务必搭配
gzip_vary on，让中间层知道该按Accept-Encoding分版本缓存 - 若使用 CDN，检查其是否默认透传
Accept-Encoding头；有些 CDN 会自动压缩，此时 Nginx 再压会导致双重压缩或冲突
验证与持续观察
配置生效≠效果达标。真实收益需靠数据验证：
- 用
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/api/data查看响应头是否有Content-Encoding: gzip - 对比压缩前后响应体大小（
curl -s -w "%{size_download}" ...），确认典型 API 响应是否稳定压缩 60%~75% - 监控 Nginx 的
gzip_ratio指标（需开启 stub_status 或通过日志分析），避免因误配导致大量小文件被低效压缩
