如何通过Nginx Gzip-Vary头部防止压缩内容缓存欺骗？

本文共计701个文字，预计阅读时间需要3分钟。

确保同时启用gzip压缩和设置Vary头，否则缓存系统可能会将gzip响应错误地发送给不支持压缩的客户端，导致页面空白或乱码。

为什么只开 gzip_vary on 不够

Nginx 的 gzip_vary on 仅在实际执行了压缩时才添加 Vary: Accept-Encoding 响应头。但若请求未携带 Accept-Encoding: gzip（比如某些旧爬虫、测试工具或禁用压缩的浏览器），Nginx 不压缩、也不加 Vary 头——此时缓存系统（CDN 或代理）会把该“未压缩响应”当作通用副本缓存，后续带 Accept-Encoding: gzip 的请求可能被错误返回未压缩内容，造成 JS/CSS 解析失败。

• 现象：同一 URL，部分用户看到空白页或控制台报 Unexpected token
• 根本原因：缓存键未区分压缩变体，Vary 缺失导致“一缓存多用”
• gzip_vary on 是条件性行为，不能保证所有响应都带 Vary

正确配置：强制统一声明 Vary: Accept-Encoding

在 location 或 server 块中显式添加 add_header Vary Accept-Encoding，覆盖 Nginx 的条件逻辑，确保每个响应（无论是否压缩）都携带该头。

• 必须放在 gzip on 启用之后，且优先级高于后端应用返回的同名头（Nginx 默认会覆盖）
• 不要用 proxy_hide_header Vary —— 这会彻底移除 Vary，加剧欺骗风险
• 若同时使用 proxy_cache，需确认 proxy_cache_key 已包含 $http_accept_encoding，否则缓存隔离失效

验证是否真正生效

用 curl 检查两个典型请求的响应头和缓存行为：

• curl -I -H "Accept-Encoding: gzip" https://yoursite.com/app.js → 应返回 Content-Encoding: gzip + Vary: Accept-Encoding
• curl -I -H "Accept-Encoding: identity" https://yoursite.com/app.js → 应返回无 Content-Encoding + 同样含 Vary: Accept-Encoding
• 两次请求的 X-Cache（或 CDN 自定义缓存标识）应分别为不同缓存条目（如 HIT / MISS 分离），而非共用一个

最容易被忽略的是：即使你只服务现代浏览器，仍可能有监控探针、安全扫描器或 iOS WebView 等客户端发送 Accept-Encoding: identity 或空头；它们一旦触发未压缩响应并被缓存，就会污染整个资源的缓存变体。强制 Vary 不是过度防御，而是补上 Nginx 默认行为的逻辑缺口。