gzip_comp_level设为4–6级是最稳妥的平衡点：4级压缩率约60%、CPU温和，适合API服务；5级约68%、均衡延迟与带宽，适合SSR站点；6级为Nginx默认值、压缩率60%–75%，适配常规官网，且需配合gzip_min_length、gzip_types、gzip_vary等配置并验证生效。
直接设为 4–6 级 是最稳妥的做法，不是越高越好，也不是越低越省事——关键看你要压什么、压给谁、服务器扛不扛得住。
压缩等级怎么选才不踩坑
gzip_comp_level 取值 1–9，但真实收益是非线性的：
- 1–3 级：压得快、CPU 几乎不涨，但 HTML/JS/CSS 通常只缩 20%–40%，适合 API 接口或容器资源紧张的场景
- 4–6 级：主流推荐区间。4 级约缩 60%、CPU 温和；5 级约 68%、延迟与带宽更均衡；6 级是 Nginx 默认值，稳定在 60%–75%，适合官网、CMS 等常规站点
- 7–9 级：比 6 级多压 3%–5%，CPU 却可能翻 4–5 倍，TTFB 明显上升，QPS 可能下降超 20%，基本不值得
光调 level 不行，配套设置必须跟上
单独改 gzip_comp_level 很容易白忙一场，这几个参数得一起配：
- gzip_min_length 1024：小于 1KB 的响应（比如 {"ok":true}）跳过压缩，避免 TCP 包头开销反超收益
- gzip_types：只列 text/html、text/css、application/javascript、application/json 等可压缩类型；明确排除 image/*、video/*、font/woff2 等已压缩格式
- gzip_vary on：让 CDN 或代理知道内容有 gzip / 非 gzip 两个版本，防止缓存错乱
- gzip_proxied any：确保经反向代理（如负载均衡器）转发的请求也能正常压缩
怎么确认真生效了
别信配置，要验证：
- 用
curl -H "Accept-Encoding: gzip" -I https://yoursite.com/test.js查响应头有没有Content-Encoding: gzip - 浏览器 Network 面板里对比 “Size”（传输体积）和 “Content”（原始体积），算出真实压缩率
- 压测时盯住 CPU 使用率（
top -p $(pgrep nginx)）和 TTFB 变化：若 CPU 持续 >70% 或 TTFB 升幅超 10%，说明等级偏高或范围太宽
特殊场景微调建议
统一设 6 是起点，但业务不同，策略也该变：
- API 服务或边缘节点：优先选 level 4，兼顾吞吐与基础压缩
- 新上线 SSR 站点：level 5 更友好，压缩率够用，CPU 更轻松
- 静态资源为主的官网：level 6 完全够用，配合
gzip_static on预压缩还能进一步减压 - 后端已返回 gzip 内容（如某些 CDN 或网关）：直接
gzip off，避免重复压缩白耗 CPU
