gzip_proxied是nginx反向代理中必须显式配置的关键指令，默认off导致via头请求不压缩；推荐生产环境使用gzip_proxied expired no-cache no-store private auth，并同步配置proxy_hide_header content-encoding和gzip_vary on。
在 CDN、WAF 或反向代理后部署 Nginx 时，gzip_proxied 不是可选项，而是必须显式配置的关键指令。默认情况下它为 off，这意味着即使你已开启 gzip on，所有经代理转发来的请求（比如带 Via 头的回源流量）都不会被压缩——响应原样透传，白白消耗带宽和回源时间。
为什么默认不压缩代理请求
Nginx 将含 Via 请求头的流量识别为“代理链路中的中间请求”，出于兼容性和安全性考虑，默认跳过压缩逻辑。而主流 CDN（阿里云、腾讯云、Cloudflare）、K8s Ingress、云 WAF 等在转发请求时都会自动注入 Via 头，导致你的 Nginx 始终认为这是“非终端用户直连”，从而放弃压缩。
不配 gzip_proxied 的典型后果
- CDN 回源响应体积大，回源带宽占用高，冷启动延迟明显上升
- JSON/API 接口返回未压缩，移动端加载变慢，首屏耗时增加
- 前端资源（JS/CSS）虽可能被 CDN 缓存压缩，但动态内容或私有接口始终裸传
- 浏览器 Network 面板看到
Content-Encoding: gzip，但实际是 CDN 层代劳压缩，Nginx 本层未参与，失去控制权
推荐配置方式与取舍
根据业务敏感性和上游是否已压缩，选择合适策略：
-
保守型（推荐生产环境）：
gzip_proxied expired no-cache no-store private auth;覆盖缓存失效、需校验、禁止缓存、私有内容、鉴权接口等常见安全可压场景，避免对图片、PDF 等二进制流误压 -
通用型（适合前后端分离+CDN 架构）：
gzip_proxied any;强制对所有代理响应启用压缩，前提是确认后端不自行压缩且不返回错误的Content-Encoding头
无论选哪种，都必须同步配置：proxy_hide_header Content-Encoding;（防双重压缩乱码）和 gzip_vary on;（确保 CDN 按 Accept-Encoding 正确缓存不同版本）。
验证是否真正生效
用 curl 模拟代理请求，而非仅看浏览器 DevTools：
curl -I -H "Via: 1.1 cdn.example" https://yoursite.com/api/user
若响应中同时包含：
Content-Encoding: gzipVary: Accept-Encoding
且响应体大小显著下降（可用 curl -w "%{size_download}" -o /dev/null -s 对比），说明配置已起效。注意：首次请求未压缩、第二次才出现，可能是 CDN 层异步压缩机制所致，不影响 Nginx 本层配置有效性。
