gzip_proxied 是反向代理场景下基于响应头特征匹配的压缩规则器，非简单开关；必须与 gzip on 共存、位于 proxy_pass 块内，且响应需满足头字段条件（如 expired/no-cache/private/auth）及长度阈值才触发压缩。
gzip_proxied 不是开关，而是规则匹配器——它只在 proxy_pass 存在时生效，且必须搭配 gzip on 才起作用；它的值决定 Nginx 是否对上游响应体执行压缩，核心在于“响应头特征识别”，而非简单开启/关闭。
gzip_proxied 的作用边界与生效前提
这个指令专用于反向代理场景，仅影响 proxy_pass 转发后收到的上游响应体。它不处理 Nginx 自身生成的静态文件（如直接 serve 的 .js/.css），也不干预非代理请求。要让它真正工作，必须同时满足：
- 全局或 location 块中已启用 gzip on（缺一不可）
- 配置位于含 proxy_pass 的 location 或 server 块内
- 上游响应需携带匹配 gzip_proxied 规则的响应头（如 Cache-Control、Expires 等）
- 响应体长度 ≥ gzip_min_length（默认 20 字节，建议设为 1024）
常用值组合及对应业务含义
推荐使用明确、安全的组合，避免无差别压缩引发风险：
- expired：响应含过期的 Expires 头 → 适合 CDN 缓存失效后回源的大体积内容（如 HTML 模板）
- no-cache / no-store：响应含 Cache-Control: no-cache 或 no-store → 动态生成的 JS/CSS/JSON，不可缓存但值得压缩
- private：响应含 Cache-Control: private → 用户专属接口（如个人中心数据），压缩降带宽且无共享缓存冲突
- auth：原始请求带 Authorization 头 → 鉴权后返回的敏感内容（如 token 刷新结果），体积常较大，压缩合理
不建议用 any，除非你明确需要强制压缩所有代理响应（例如前端统一走 CDN + WAF 的架构），否则可能对图片、字体等已压缩资源造成二次乱码或体积膨胀。
必须同步处理的三项关键配套
仅配 gzip_proxied 远不够，以下三点漏掉任一都会导致压缩失效：
- proxy_hide_header Content-Encoding：移除上游误设的 Content-Encoding: gzip，防止 Nginx 跳过压缩或触发双重压缩
- gzip_vary on：让 CDN 和浏览器知道响应是否依赖 Accept-Encoding，避免缓存错乱（如把未压缩版本缓存后返回给支持 gzip 的客户端）
- 关闭后端自身压缩：如 Express 的 compression()、Tomcat 的 compression="on"，否则易出现“上游已压 → Nginx 再压 → 二进制乱码”
验证是否生效的实操方式
别只看配置，用真实请求确认：
- 用 curl 测试：curl -H "Accept-Encoding: gzip" -I https://yoursite.com/api/data，检查返回头是否有 Content-Encoding: gzip 和 Vary: Accept-Encoding
- 对比直连后端与经 Nginx 代理的响应头差异，确认压缩行为由 Nginx 发起
- 查看 access log 中 $gzip_ratio 变量：非破折号（如 0.35）表示成功压缩，- 表示未压缩
- 检查 upstream 是否确实返回了匹配条件的响应头（如 Cache-Control: no-cache）
