gzip压缩在多级代理下失效是因nginx默认拒绝对含via头的请求压缩，需配置gzip_proxied并确保gzip_vary、gzip_http_version等生效，且避免上游误设content-encoding。
多级代理环境下 Gzip 压缩失效，不是“没开压缩”，而是 Nginx 主动跳过了压缩——它默认拒绝给带 Via 头的请求压缩响应。排查要直击这个逻辑断点，而不是反复检查 gzip on 是否存在。
看请求是否触发了代理压缩判断
Nginx 只在请求头含 Via 字段时才走 gzip_proxied 分支。CDN、WAF、前置 Nginx 回源都会加该头。
- 用
curl -I -H "Via: 1.1 cdn" https://yoursite.com/api/data模拟代理请求，观察响应是否有Content-Encoding: gzip - 对比直连源站（绕过 CDN）的响应头：若直连有压缩、走 CDN 就没有，说明问题出在代理链路的压缩策略上
- 检查浏览器 Network 面板里任意接口响应头，确认
Via是否真实存在（有些 CDN 会隐藏，但回源请求一定带）
查 gzip_proxied 是否生效且配置合理
这是最常被忽略的核心配置。默认值是 off，不显式设置就等于关闭代理压缩。
- 确认配置中写了
gzip_proxied expired no-cache no-store private auth;，而非any或留空 -
any虽能临时让压缩出现，但会误压图片、字体等二进制资源，导致乱码或体积变大 - 如果后端返回了
Cache-Control: no-cache或Expires过期，而 Nginx 却没压缩，说明gzip_proxied没覆盖对应语义
防上游干扰和头污染
后端服务若错误地设置了 Content-Encoding: gzip 但 body 并未真正压缩，Nginx 再次压缩就会损坏响应。
- 在
location或server块中添加proxy_hide_header Content-Encoding;，强制剥离上游误设的编码头 - 确保后端代码不手动写
Content-Encoding，除非它自己完成了压缩并生成了 gzip body - 开启
gzip_vary on;，让 CDN 和浏览器知道该响应依赖Accept-Encoding，避免缓存混用
验证协议与响应头完整性
HTTP/1.0 回源请求可能被 Nginx 忽略压缩；缺少关键响应头也会导致前端无法识别压缩流。
- 加上
gzip_http_version 1.0 1.1;，兼容老旧网关或某些 WAF 的 HTTP/1.0 回源 - 确认
gzip_types包含动态内容类型：application/json text/html application/javascript等 - 响应头必须同时出现
Content-Encoding: gzip和Vary: Accept-Encoding，缺一不可
