必须同时启用 gzip_vary on 和显式 add_header Vary Accept-Encoding，否则缓存系统可能把 gzip 响应错发给不支持压缩的客户端，导致页面空白或乱码。
必须同时启用 gzip_vary on 和显式 add_header Vary Accept-Encoding，否则缓存系统可能把 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 默认行为的逻辑缺口。
