应设 gzip_min_length 为 1024 并确保响应带 content-length 头，以避免小体量状态码响应（如 204、302、404）被误压缩导致膨胀和 cpu 浪费。
直接设为 1024（即 1k），并确保响应带 Content-Length 头——这是避免对小体量状态码响应（如 204、302、404）二次压缩最有效的方式。
为什么状态码响应容易被误压
像 204 No Content、302 Found、401 Unauthorized 这类响应，本身没有响应体或只有极短的 body（几十字节），但若 Nginx 未限制最小长度，且恰好匹配了 gzip_types 中的默认类型（如 text/html），就可能触发压缩。而 gzip 压缩头至少增加 10–20 字节开销，导致“越压越大”，还白白消耗 CPU。
更隐蔽的问题是：某些框架（如 Express、Django）返回空响应时仍会写 Content-Length: 0，而 Nginx 的 gzip_min_length 对 0 值不生效（它只跳过 小于设定值 的非零长度响应）。所以关键不是状态码本身，而是响应体真实字节数 + 是否带可读的 Content-Length。
配置要点：让 gzip\_min\_length 真正管用
-
显式设值而非依赖默认：Nginx 默认
gzip_min_length 20，太低，必须覆盖为1024或更高 - 确认响应有 Content-Length：动态接口（如 PHP、Node.js）需主动设置该 header；静态文件天然具备；无 body 的响应（204/304）不应设该头，Nginx 自动跳过压缩
-
收紧 gzip_types：不要包含
text/html以外的泛类型（如application/json要谨慎），避免 200 OK 的空 JSON（{}）被误压。推荐只列真正需要压缩的文本类型：text/css text/javascript application/javascript text/plain -
禁用对空响应的压缩尝试：配合
gzip_proxied no-cache no-store private expired auth;，防止反向代理场景下缓存层绕过判断
验证是否对状态码响应生效
用 curl 检查典型小响应：
- 访问一个返回 302 的路径：
curl -I -H 'Accept-Encoding: gzip' https://yoursite.com/redirect—— 若响应含Content-Length: 0或无 body，应 无Content-Encoding: gzip - 访问一个返回精简 HTML 的 404 页面（约 300 字节）：
curl -s -w '\n%{size_download}\n' -o /dev/null -H 'Accept-Encoding: gzip' https://yoursite.com/404.html—— 下载大小应接近原始字节数，且响应头不含Content-Encoding - 对比一个 1.5KB 的正常 JS 文件，应看到
Content-Encoding: gzip和明显减小的Content-Length
补充建议：从源头减少小响应生成
压缩只是补救，更优解是减少小响应本身：
- 对纯重定向（301/302），用
return 302 https://xxx;而非后端渲染 HTML，避免产生任何 body - API 接口返回空成功响应时，优先用 204 而非 200 +
{}，Nginx 不会对 204 响应体做压缩判断（因无 body） - 自定义错误页（404/50x）保持简洁，控制在 1k 以内，并确保 Nginx 静态提供（自动带
Content-Length）
