要让nginx对反向代理响应启用gzip压缩，必须同时开启gzip on并配置gzip_proxied匹配条件（如no-cache no-store private expired auth），且需配合proxy_hide_header content-encoding、gzip_vary on、关闭后端压缩及设置gzip_min_length。
要让 Nginx 对反向代理后端返回的响应启用 gzip 压缩，仅开启 gzip on 是不够的。关键在于用 gzip_proxied 显式接管压缩决策权——它才是真正控制“是否压缩代理响应”的开关。
必须同时满足的两个前提
gzip_proxied 不是独立生效的指令，它依赖以下基础配置：
- gzip on; —— 全局压缩开关，必须开启，否则所有 gzip 相关指令（包括 gzip_proxied）都不起作用
- 配置了 proxy_pass 的 location 或 server 块 —— gzip_proxied 只在反向代理上下文中生效，静态文件服务不走这条路径
设置合理的匹配条件
gzip_proxied 的值是一组空格分隔的条件标记，Nginx 收到上游响应后，检查其响应头是否满足任一条件，满足即触发压缩。推荐生产环境使用：
-
no-cache：响应含
Cache-Control: no-cache，适合动态接口、不缓存但体积大的内容 -
no-store：响应含
Cache-Control: no-store，明确禁止缓存，压缩安全 -
private：响应含
Cache-Control: private，如用户专属数据，压缩可降带宽 -
expired：响应含
Expires头且已过期，常用于缓存穿透回源场景 -
auth：原始请求带
Authorization头，鉴权后响应通常未压缩、体积大
完整写法示例：gzip_proxied no-cache no-store private expired auth;
配套必须做的几件事
光配对条件还不够，以下操作能避免常见失效问题：
-
剥离上游误传的 Content-Encoding：加
proxy_hide_header Content-Encoding;，防止后端错误返回该头导致 Nginx 跳过压缩 -
开启 Vary 支持：加
gzip_vary on;，让 CDN 或浏览器知道响应是否依赖Accept-Encoding，避免缓存错乱 - 确认后端不自行压缩：关闭 Express、Spring Boot 等框架的内置压缩中间件，统一由 Nginx 集中处理，防双重压缩或乱码
-
设置最小压缩长度：加
gzip_min_length 1024;，避免压缩极小响应（如短 JSON）反而增大体积
验证是否真正生效
不要只看配置，要实测：
- 用
curl -H "Accept-Encoding: gzip" -I https://your-domain/api/test查看响应头是否有Content-Encoding: gzip和Vary: Accept-Encoding - 对比绕过 Nginx 直连后端的响应头，确认上游确实返回了
Cache-Control: no-cache等匹配字段 - 检查 access log 中
$gzip_ratio变量，非破折号（如 0.32）表示成功压缩
