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 或反向代理的缓存键计算逻辑。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

配合缓存头提升客户端复用效率

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-Encoding
• Content-Encoding: gzip

这两项共同表明：Nginx 正确识别了客户端能力，生成了压缩响应，并向缓存系统明确声明了变体依据——这是 HTTP 缓存一致性最基础也最关键的信号。