Nginx在CDN回源时需配置gzip_proxied expired no-cache no-store private auth才能启用Gzip压缩，因默认忽略Via头代理请求；还需proxy_hide_header Content-Encoding和gzip_vary on。
想让 Nginx 在 CDN 回源场景下对后端响应启用 Gzip 压缩，关键不是只开 gzip on，而是必须正确配置 gzip_proxied——它决定了 Nginx 是否会对代理返回的内容进行压缩。默认值是 off，也就是说，哪怕 gzip 已开启，只要没配好这个指令，CDN 回源时的响应依然不压缩。
为什么 CDN 回源常不压缩？
Nginx 默认将带 Via 请求头的流量识别为代理请求，并直接跳过压缩逻辑。而 CDN（如腾讯云、阿里云）回源时一定会带上 Via 头，这就导致上游响应原样透传，未压缩传输，白白浪费带宽和回源时间。
推荐的 gzip_proxied 配置组合
在多级代理（CDN → Nginx → 后端）中，应根据响应缓存策略和敏感性来启用压缩，而不是无差别开启。生产环境建议使用：
-
expired：响应含
Expires且已过期，说明内容可安全压缩 -
no-cache：
Cache-Control: no-cache表示可缓存但需校验，压缩不影响语义 - no-store：禁止缓存，但压缩仍可提升传输效率
- private：仅用户私有缓存，适合登录态内容，压缩无风险
-
auth：带
Authorization头的请求，通常对应动态接口，压缩能明显减小 JSON 响应体
完整配置示例：
gzip_proxied expired no-cache no-store private auth;配套必须做的两件事
光配 gzip_proxied 不够，还需同步处理两个常见副作用：
- 加
proxy_hide_header Content-Encoding：防止后端已压缩、Nginx 又二次压缩，造成乱码或解压失败 - 开
gzip_vary on：让 Nginx 自动添加Vary: Accept-Encoding响应头，确保 CDN 节点按是否支持 gzip 分别缓存，避免压缩版被不支持 gzip 的客户端错误命中
验证是否生效
用 curl 模拟 CDN 回源请求（手动加 Via 头），检查响应头是否有 Content-Encoding: gzip：
同时确认响应体大小明显小于未压缩时（可用 --write-out "%{size_download}" 对比）。若首次访问未压缩，第二次才出现，可能是 CDN 层采用异步压缩机制（如腾讯云主动压缩），属正常行为，不影响 Nginx 本层配置有效性。
