gzip_vary on是保障缓存正确性的必要配置，它由Nginx内部逻辑精准控制，仅在实际执行gzip压缩时自动添加Vary: Accept-Encoding响应头，避免未压缩响应被误判为依赖编码变体。
开启 gzip_vary on 是处理 Vary 响应头的核心方式，它不是可选优化，而是保障客户端缓存正确性的必要配置。
为什么必须用 gzip_vary 控制 Vary 头
Nginx 启用 gzip 后，对同一 URL 可能返回两种响应：
- 客户端不带
Accept-Encoding: gzip→ 返回明文内容 - 客户端声明支持 gzip → 返回 gzip 压缩流
若响应中缺失 Vary: Accept-Encoding，浏览器、CDN 或代理会把这两类响应当成“完全一样”来缓存。结果就是：压缩版被缓存后，错发给不支持解压的老设备，导致页面空白或 JS 执行失败。
gzip_vary on 的关键价值在于——它由 Nginx 内部逻辑精准控制：仅当实际执行了压缩时，才添加该响应头；未压缩的响应（如图片、.gz 文件、或因 gzip_min_length 未达标而跳过压缩）则不加。这避免了缓存系统误判“所有响应都依赖 Accept-Encoding”，造成冗余缓存或策略混乱。
正确配置方式（无需手动 add_header）
在 http 或 server 块中启用以下两项即可：
-
gzip on;—— 开启压缩功能 -
gzip_vary on;—— 自动注入Vary: Accept-Encoding，且仅限压缩生效时
不要写 add_header Vary Accept-Encoding;。这种写法无条件添加，会导致未压缩响应也带上 Vary 头，浪费缓存空间，还可能干扰 CDN 或反向代理的缓存键计算逻辑。
配合缓存头提升客户端复用效率
Vary 头只解决“缓存区分问题”，要让压缩资源真正被浏览器长期复用，还需搭配合适的缓存控制头：
- 对静态资源（JS/CSS/JSON等），在
location中设置：expires 1y;或add_header Cache-Control "public, immutable, max-age=31536000"; - 确保
Cache-Control不含no-cache或no-store，否则浏览器不会缓存压缩后的字节流 - 注意：浏览器缓存的是已压缩的完整响应体，不是“先解压再缓存”，所以 Content-Encoding + Cache-Control + Vary 三者必须协同生效
验证是否生效的简单方法
用 curl 模拟支持 gzip 的客户端请求：
curl -I -H "Accept-Encoding: gzip" https://yoursite.com/app.js成功响应应同时包含：
Vary: Accept-EncodingContent-Encoding: gzip
这两项共同表明：Nginx 正确识别了客户端能力，生成了压缩响应，并向缓存系统明确声明了变体依据——这是 HTTP 缓存一致性最基础也最关键的信号。
