典型表现是接口乱码、JSON解析失败、CSS/JS无法执行或浏览器提示“invalid compressed data”，根本原因是后端已压缩响应（如Spring Boot启用compression）而Nginx又误配proxy_hide_header Content-Encoding导致二次压缩，或后端伪造Content-Encoding头但未实际压缩。
代理后端响应被重复 Gzip 压缩，典型表现是接口返回乱码、JSON 解析失败、CSS/JS 无法执行，或浏览器提示“invalid compressed data”。这不是 Nginx 配置漏了，而是压缩动作在多个环节叠加——后端已压，Nginx 又压了一次。排查要聚焦“谁先压、谁又压、谁该停”。
确认后端是否已压缩响应
这是起点。Nginx 默认不压缩 proxy_pass 返回的内容，除非你开了 gzip on；但若后端（如 Spring Boot、Express、Django）自己启用了压缩中间件，它可能已返回带 Content-Encoding: gzip 的响应体。
- 用
curl -I http://your-nginx/api/data查响应头：若已有Content-Encoding: gzip，说明后端已压缩 - 再查
$upstream_http_content_encoding日志变量（需在 log_format 中加入），确认上游真实返回的编码头 - 检查后端配置：比如 Node.js 的
compression()、Tomcat 的compression="on"、Spring Boot 的server.compression.enabled=true
检查 Nginx 是否对已压缩响应再次压缩
Nginx 在收到含 Content-Encoding: gzip 的上游响应时，默认会透传，不再压缩。但如果配置不当，仍可能触发二次处理：
- 确保没在 location 中误写
gzip on+proxy_pass，且未配合proxy_hide_header Content-Encoding - 若加了
proxy_hide_header Content-Encoding，Nginx 就“看不见”上游已压缩，会按规则重新压缩——这正是乱码主因 - 验证方式：临时注释掉
proxy_hide_header Content-Encoding，再 curl 测试，看乱码是否消失
识别并拦截错误的 Content-Encoding 干扰
更隐蔽的情况是：后端声称自己压缩了（写了 Content-Encoding: gzip），但 body 实际未压缩。Nginx 看到头就透传，浏览器解压失败，直接报错。
- 用
curl -s http://your-nginx/api/data | file -检查响应体是否为 gzip 格式（应显示 “gzip compressed data”） - 若显示 “data” 或 “text/plain”，说明后端伪造了头——必须修复后端逻辑，不能只靠 Nginx 拦截
- 作为兜底，在对应 location 中强制移除该头：
proxy_hide_header Content-Encoding;
验证最终响应是否符合解压预期
浏览器能否正确解压，不仅取决于压缩本身，还依赖响应头完整性：
- 响应必须同时包含：
Content-Encoding: gzip和Vary: Accept-Encoding - 若只有前者没有后者，CDN 或代理可能缓存错版本，导致部分用户收到未压缩内容
- 用
curl -H "Accept-Encoding: gzip" -s http://your-nginx/api/data | gunzip -t直接测试解压有效性（返回 0 表示成功）
