Linux下启用Nginx的gunzip模块需先确认编译时加入--with-http_gunzip_module，再在配置中显式设置gunzip on;，它仅对客户端不支持gzip时解压后端返回的gzip响应。

Linux 下让 Nginx 启用 gunzip 模块自动解压响应内容，核心是两步：确认模块已编译进 Nginx，再在配置中正确开启并限定触发条件。它不是“默认可用”的功能，也不能靠改几行配置就生效——模块缺失时，配置会直接报错。

确认 gunzip 模块是否已编译

该模块不随 gzip 模块自动启用，必须显式编译。运行以下命令检查：

• nginx -V 2>&1 | grep -o with-http_gunzip_module

如果输出为空，说明当前 Nginx 二进制文件不含该模块。此时无法通过 reload 或修改配置启用，只能重新编译 Nginx，并在 ./configure 阶段加入：
--with-http_gunzip_module

基础配置：全局或局部启用 gunzip

模块存在后，在 http、server 或 location 块中添加：

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

• gunzip on; —— 必须显式开启，否则不工作
• gunzip_buffers 16 8k; —— 控制解压内存缓冲，默认 32 4k，可根据响应大小微调

注意：gunzip 只对后端返回且带 Content-Encoding: gzip 的响应起作用；它不会压缩，只解压。是否真正触发解压，取决于客户端是否声明支持 gzip（即请求头含 Accept-Encoding: gzip）——只有当客户端不支持时，Nginx 才会解压后转发明文。

配合 gzip 模块控制兼容性逻辑

gunzip 和 gzip 指令协同工作。常见搭配如下：

• gzip_disable "msie6"; —— 对 IE6 禁用压缩，同时也会让 gunzip 在遇到这类客户端时更倾向解压
• gzip_vary on; —— 让 Nginx 返回 Vary: Accept-Encoding 头，避免代理缓存混淆
• gzip_proxied any; —— 若后端返回的响应本身已带 Content-Encoding: gzip，此设置可确保 Nginx 将其视作可处理对象（便于后续 gunzip 判断）

也就是说，gunzip 不是无条件解压所有 gzip 响应，而是按策略判断“这个客户端值不值得发明文”。没有 gzip 相关配置配合，gunzip 很可能始终不触发。

典型使用场景示例

比如你用 Nginx 代理一个返回 gzip 响应的 API 服务，但某些老旧终端不支持 gzip 解压：

• 在对应 location /api/ 块内写：
  

  gunzip on;<br>proxy_pass http://backend;

• 确保 http 块中已有 gzip on; 和合理的 gzip_disable 规则
• 验证方式：用不带 Accept-Encoding 头的 curl 请求，抓包看响应是否无 Content-Encoding 且内容可读