必须开启gzip_vary on并显式add_header Vary Accept-Encoding，否则缓存系统可能将gzip响应错发给不支持压缩的客户端，导致页面空白或乱码；因nginx仅在实际压缩时才加Vary头，未压缩响应若无Vary声明会被当作通用副本缓存。
配置 gzip_vary 的核心目的，是让客户端（尤其是浏览器和中间缓存层）明确知道：当前响应是否经过 gzip 压缩，且该响应内容会随请求头 Accept-Encoding 的不同而变化。
为什么必须开启 gzip_vary
当 Nginx 对响应启用 gzip 压缩后，同一 URL 可能返回两种内容：
- 未压缩的明文（客户端不带
Accept-Encoding: gzip） - 压缩后的 gzip 流（客户端声明支持 gzip）
若响应头中缺少 Vary: Accept-Encoding，CDN、反向代理或浏览器缓存可能把压缩版错误地缓存并返回给不支持 gzip 的客户端，导致页面乱码或脚本执行失败。
正确配置 gzip_vary 的方式
在 Nginx 的 http 或 server 块中添加：
gzip on; gzip_vary on;
无需额外指定值，on 即表示自动插入 Vary: Accept-Encoding 响应头。这是默认推荐行为，适用于绝大多数场景——包括自建服务器、云主机、以及接入 CDN 但未开启“自动压缩”功能的情况。
什么情况下可以关闭 gzip_vary
仅在以下明确可控的前提下才考虑设为 off：
- 你使用的 CDN 已统一接管所有响应，并对所有支持 gzip 的终端强制返回压缩内容（如 Cloudflare 的 Auto Minify + Brotli 启用时）
- 全站资源已预压缩为
.gz文件并启用gzip_static on，且 Nginx 不再做动态压缩 - 服务完全不经过任何中间缓存，纯直连客户端（如内网 API 网关）
普通网站、含 CDN 的生产环境、或使用反向代理（如 Nginx → Node.js）的架构，一律保持 gzip_vary on。
验证是否生效
发起带压缩能力声明的请求，检查响应头：
curl -I -H "Accept-Encoding: gzip" https://yoursite.com/style.css
若返回中包含：
Vary: Accept-Encoding Content-Encoding: gzip
说明 gzip_vary 已正确协同工作——它告诉缓存：“这个响应依赖于 Accept-Encoding，请按此维度分别缓存。”
