gunzip模块是Nginx对已压缩响应的兼容性解压机制，仅在后端返回gzip内容且客户端不支持时生效，需同时满足响应头含Content-Encoding: gzip、请求头无Accept-Encoding: gzip、配置gunzip on且MIME类型匹配等条件。
gunzip 模块不是用来“让不支持压缩的客户端获得压缩效果”，而是当后端已返回 gzip 压缩内容、但客户端无法解压时，由 Nginx 主动解压后再发出去——本质是兼容兜底，不是性能优化。
明确适用场景和触发条件
gunzip 只在同时满足以下全部条件时才生效：
- 后端响应头中包含 Content-Encoding: gzip（例如静态文件启用了 gzip_static，或上游服务固定返回 gzip 内容）
- 客户端请求头中 Accept-Encoding 不含 gzip（如为空、仅含 identity，或压根没带该头）
- Nginx 配置了 gunzip on，且未被 location 级别的 gunzip off 覆盖
- 响应 MIME 类型匹配 gunzip_types 列表（默认含 text/plain、text/css、application/javascript 等）
在 http 块中安全启用
若全站需统一兼容老旧客户端（如部分爬虫、嵌入式设备、旧版浏览器），推荐在 http{} 块中配置：
- gunzip on;
- gunzip_types text/plain text/css application/javascript application/json application/xml;（按实际返回类型补充）
- gunzip_min_length 1000;（避免对极小响应（如空 JS 或短 JSON）额外解压开销）
- 可选：gunzip_buffers 16 8k;（调整内存缓冲，适配大响应；默认 32×4k 通常够用）
注意：此配置不影响未压缩响应，也不改变 gzip 模块行为；gzip 和 gunzip 可共存，互不干扰。
验证是否真正生效
用 curl 模拟不支持 gzip 的客户端，观察响应变化：
- 执行：
curl -I -H "Accept-Encoding:" https://your-site/example.js - 检查响应头：不应再出现 Content-Encoding: gzip，且 Content-Length 应明显增大
- 再执行：
curl -sN -H "Accept-Encoding:" https://your-site/example.js | head -c 50 - 确认输出是明文 JS 代码（如
function init(){...），而非乱码或二进制流
避开常见误解与风险
以下做法没有意义，甚至有害：
- 对本就不带 gzip 编码的响应开启 gunzip —— 完全不触发，纯属冗余
- 期望 gunzip 能提升传输效率 —— 它只增加 CPU 开销，不减少网络字节数
- 在未确认后端真实返回 gzip 响应的前提下盲目开启 —— 可能掩盖上游配置错误
- 忽略 MIME 类型限制，却指望它解压 image/svg+xml 或 font/woff2 —— 默认不匹配，需显式加入 gunzip_types
