ngx_http_gunzip_module的核心价值是按需解压缓存中的gzip内容并分发，适用于不支持gzip编码的老旧终端；需手动编译启用，触发条件包括响应头含Content-Encoding: gzip、客户端未声明Accept-Encoding: gzip、gunzip on开启且gzip模块启用。
ngx_http_gunzip_module 的核心价值，是在不修改后端服务、不重压 CPU 做实时解压的前提下，让 Nginx 在缓存层对已压缩内容做“按需解压分发”。特别适合老旧移动设备、嵌入式终端或某些浏览器（如旧版 IE、部分 IoT 客户端）无法处理 Content-Encoding: gzip 响应的场景。
它不是替代 gzip 模块，而是与之协同：后端或缓存中存的是 gzip 压缩体（节省磁盘/带宽），Nginx 根据客户端能力决定是否在发出前解压——整个过程对上游透明，也无需额外解压服务。
确认模块已启用并理解触发条件
该模块不随 Nginx 默认编译，需确认安装时包含 --with-http_gunzip_module。可通过以下命令验证：
nginx -V 2>&1 | grep -o with-http_gunzip_module
若无输出，需重新编译或换用支持该模块的发行版（如 OpenResty 或某些 Linux 发行版预编译包）。
触发解压有严格前提，缺一不可：
- 后端响应头含
Content-Encoding: gzip - 客户端请求头 未声明
Accept-Encoding: gzip（或被gzip_disable显式排除） -
gunzip on已在对应作用域开启（http/server/location） -
gzip模块本身需启用（用于判断客户端兼容性逻辑，即使不压缩出站）
⚠️ 注意：
gunzip不会解压非 gzip 编码内容，也不处理br、zstd等其他编码；它只响应gzip编码且客户端不支持时的“降级透传”。
在缓存路径中精准启用 gunzip
推荐将 gunzip on 限定在明确走缓存的 location，避免全局开销。例如：
location /static/ {
alias /data/cache/;
gunzip on;
# 若使用 proxy_cache 或 fastcgi_cache，此处仍生效
# 因为 gunzip 是 response filter，在 cache read 之后、send 之前介入
}关键点：
-
gunzip对proxy_cache、fastcgi_cache、scgi_cache和本地文件（alias/root）均有效 - 解压发生在 Nginx 读取缓存体之后、写入 socket 之前，不改变缓存文件本身格式
- 即使缓存中存的是
.gz文件（配合gzip_static on），只要响应头是Content-Encoding: gzip，gunzip仍可介入解压
调优缓冲区以适配旧设备小内存
旧设备常伴随低带宽、小 TCP 窗口、弱内存，gunzip_buffers 需兼顾解压效率与内存占用：
gunzip_buffers 8 4k; # 8个4KB缓冲，共32KB，适合低配终端
说明：
-
number过大会增加内存驻留（尤其高并发时），旧设备并不需要大缓冲 -
size设为 4K 是安全起点（匹配多数页大小），8K 可能导致部分 ARM 设备解压失败 - 不建议设为
16 8k或更高——这不是性能优化项，而是稳定性控制项
若日志中频繁出现 * * * gunzip: out of memory，说明缓冲不足，可小幅上调 number，但优先检查是否误将 gunzip on 放在了非 gzip 响应路径下。
配合 gzip_vary 实现智能缓存区分
为避免 gzip 与非 gzip 响应混存导致错发，必须启用：
gzip_vary on;
效果：
- Nginx 自动在响应头添加
Vary: Accept-Encoding - 下游缓存（CDN、代理、浏览器）据此区分存储 gzip 和非 gzip 版本
-
gunzip解压后的响应会被标记为Vary: Accept-Encoding+ 无Content-Encoding头，确保不会被错误复用给支持 gzip 的客户端
没有 gzip_vary，可能出现：
- 缓存命中 gzip 响应，却发给不支持 gzip 的客户端（报错或乱码）
- 或反向：把 gunzip 解压后的内容缓存下来，又错发给支持 gzip 的客户端（浪费带宽）
所以 gunzip 和 gzip_vary 是一对绑定配置，不可拆分。
不复杂但容易忽略。
