ngx_http_gunzip_module 的作用是条件性解压后端返回的 gzip 编码响应，供不支持 gzip 的旧客户端使用；需同时满足：响应含 Content-Encoding: gzip、客户端未声明 Accept-Encoding: gzip、配置 gunzip on 且 MIME 类型匹配 gunzip_types。
ngx_http_gunzip_module 的作用不是“给旧客户端加压缩”，而是当后端（比如静态文件服务或上游应用）已返回 gzip 编码内容、但客户端不支持 gzip 时，由 Nginx 主动解压后再发出去——让旧设备能正常读取文本资源，不出现乱码或解析失败。
明确适用场景和前提条件
gunzip 生效必须同时满足以下四点：
- 响应头中包含 Content-Encoding: gzip（说明后端/缓存已压缩）
- 客户端请求头中 Accept-Encoding 不含 gzip（如空值、只含 identity，或根本没带该头）
- Nginx 配置了 gunzip on，且未被更细粒度作用域（如 location）关闭
- 响应 MIME 类型匹配 gunzip_types 列表（默认含 text/plain、text/css、application/javascript 等）
在 http 块中统一启用 gunzip
若所有静态资源（如 /static/、/assets/ 下的 JS/CSS/JSON）均由 Nginx 直接提供或经 upstream 返回 gzip 内容，推荐在全局 http 块配置：
http {
gunzip on;
gunzip_types text/plain text/css application/javascript application/json application/xml;
gunzip_min_length 1000; # 小于 1KB 的响应跳过解压，省 CPU
}
注意：gunzip 不会改变未压缩的响应，也不会主动压缩；它只对已带 gzip 编码的响应做条件性解压。
配合 gzip 模块实现兼容+高效双模式
gunzip 和 gzip 可共存。典型组合如下：
- gzip on：对支持 gzip 的现代客户端，Nginx 自行压缩响应（提升传输效率）
- gunzip on：对不支持 gzip 的旧客户端，Nginx 解压后端返回的 gzip 内容（保障可读性）
- 二者互不干扰——gzip 处理的是“原始未压缩响应”，gunzip 处理的是“已含 gzip 编码的响应”
例如后端固定返回预压缩的 .gz 文件（通过 gzip_static on），或反向代理上游始终返回 gzip 响应，此时 gunzip 就是兜底关键。
验证是否按预期工作
用 curl 模拟老旧客户端请求，检查响应是否被正确解压：
# 不发送 Accept-Encoding 头（模拟 IE6、旧爬虫等） curl -I -H "Accept-Encoding:" http://example.com/app.js
观察响应头：
- 若 Content-Encoding: gzip 已消失，且 Vary 头仍存在，说明 gunzip 触发成功
- 再用
curl -s http://example.com/app.js查看响应体——应为可读 JS 文本，而非二进制乱码
如果仍看到 gzip 编码头或响应不可读，需检查后端是否真返回了 gzip 内容、MIME 类型是否在 gunzip_types 中、以及是否有 location 块覆盖了 gunzip on 设置。
