设 gzip_min_length 1024 可避免小文件越压越大和CPU浪费，因默认20字节过低易致压缩后体积增加；需配合 gzip_types、Content-Length 设置、禁用双重压缩及收紧 gzip_proxied 规则。
直接设 gzip_min_length 1024，就能有效阻止对小文件的 gzip 压缩，避免“越压越大”和 CPU 白耗。
为什么必须设 1024 而不是默认值
nginx 默认 gzip_min_length 20，太低——几十字节的响应（如空 204、简短 302、精简 JSON）一旦被压缩，gzip 头部加元数据就占 10–20 字节，结果体积反而增加，还多花 CPU。设为 1024 是经过大量实测验证的平衡点：既跳过无价值的小响应，又覆盖绝大多数真正可压缩的文本内容（如带样式的 HTML 片段、中等 JS 模块）。
光设 min_length 不够，还得配齐这几项
-
显式声明 gzip_types：只列真实需要压缩的类型，比如
text/css application/javascript text/plain；别盲目加application/json或text/html泛类型，否则空 JSON{}或极简 404 页面容易被误压 - 确保响应带 Content-Length 头：动态接口（PHP/Node.js）需后端主动设置；静态文件天然具备；无 body 的响应（204/304）不应设该头，Nginx 才能准确判断长度
- 禁用双重压缩干扰：若用了 CDN，源站要关掉原生压缩（或仅作兜底），避免 CDN + Nginx 同时压缩导致解析异常
-
收紧 gzip_proxied 规则：加上
gzip_proxied no-cache no-store private expired auth;，防止反向代理绕过最小长度判断
怎么验证它真起作用了
别只看配置写了没，用 curl 实测真实响应：
- 访问一个返回 300 字节的健康检查接口：
curl -I -H 'Accept-Encoding: gzip' https://site.com/health—— 响应头里不该出现Content-Encoding: gzip，Content-Length应接近原始大小 - 对比一个 1.5KB 的 JS 文件：
curl -s -w '\n%{size_download}\n' -o /dev/null -H 'Accept-Encoding: gzip' https://site.com/app.js—— 应看到Content-Encoding: gzip和明显变小的Content-Length - 特别留意 302/404 这类状态码页面：如果它们体积小又没设好，最容易暴露误压问题
顺手优化：从源头减少小响应
压缩只是补救，更优解是少生成小响应本身：
- 纯重定向（301/302）尽量用 Nginx 的
return 302 https://xxx;，别走后端渲染 - API 返回空内容时，优先用 204 状态码并确保不写 body，比返回空 JSON 更轻量
- 自定义错误页（404/500）控制在 1KB 以内，或干脆用 CDN 缓存的静态页替代动态生成
