返回
创建于
状态公开

深入解析因缺失 Vary: Origin 引发的缓存污染问题

现象与问题本质

当多个站点（如主站与测试环境）共享同一静态资源 URL 时，浏览器基于 URL 的缓存机制会导致跨域响应头污染。具体表现为：首次访问主站获取的 Access-Control-Allow-Origin: https://powerfulyang.com 会被缓存，当测试站点访问同一资源时，浏览器错误地使用已缓存响应头，触发 CORS 错误。

缓存污染示意图

底层机制剖析

HTTP 缓存键生成规则

浏览器缓存系统通过复合键机制存储响应：

javascript
1cache_key = hash(
2  request_method + 
3  request_url + 
4  vary_headers_values
5)

当服务端未声明 Vary: Origin 时，缓存系统默认仅根据 URL 和请求方法生成缓存键，忽略 Origin 头的差异。

CORS 预检机制

对于字体等非简单请求，浏览器会执行预检（Preflight）流程。但若资源已缓存：

  1. 实际请求直接从缓存读取
  2. 预检请求可能被跳过
  3. 缓存中的错误 CORS 头直接生效

CDN 的特殊处理

主流 CDN 对 Vary 头支持存在差异：

  • Cloudflare：自动展开 Vary: User-Agent 为多缓存副本
  • AWS CloudFront：需配合 Cache Policy 显式配置
  • 阿里云 CDN：默认最多支持 4 个 Vary 参数

解决方案对比

方案一：设置 Vary: Origin（推荐）

nginx
1location /fonts/ {
2    add_header Vary Origin;
3    add_header Access-Control-Allow-Origin $http_origin;
4    add_header Access-Control-Allow-Credentials true;
5}

优势：

  • 符合 HTTP 规范
  • 支持多域名场景
  • 兼容身份凭证（credentials）

风险：

  • 可能造成缓存碎片化（每个 Origin 独立缓存）
  • 需监控 CDN 缓存命中率

方案二：通配符 Access-Control-Allow-Origin（快速修复）

nginx
1add_header Access-Control-Allow-Origin "*";

限制：

  • 与 Access-Control-Allow-Credentials: true 互斥
  • 存在安全风险（允许任意源访问）
  • 不符合 OWASP 安全规范

方案三：URL 版本化（长期方案）

html
1<link href="https://static.example.com/fonts/zpix_v2.woff?env=prod">

通过 URL 路径参数区分环境，完全避免缓存冲突。适用于高频更新的静态资源。

工程实践要点

缓存控制策略优化

建议组合使用缓存指令：

http
1Cache-Control: public, max-age=31536000, immutable
2Vary: Origin, Accept-Encoding
  • immutable 防止浏览器强制验证
  • 兼容性处理：Safari 对 immutable 支持较弱

监控与调试

推荐使用 Chrome 开发者工具的 Network 面板检查：

  1. 响应头中 Vary 值是否正确
  2. 缓存状态显示为 from disk cache 时的 CORS 头
  3. 使用 chrome://net-export 捕获完整网络日志

服务端最佳实践

go
1func CORSHandler(w http.ResponseWriter, r *http.Request) {
2    origin := r.Header.Get("Origin")
3    if allowedOrigins[origin] {
4        w.Header().Set("Access-Control-Allow-Origin", origin)
5        w.Header().Set("Vary", "Origin")
6    } else {
7        w.WriteHeader(http.StatusForbidden)
8    }
9}

动态验证 Origin 白名单，避免开放通配符带来的安全隐患。

争议与陷阱

Vary 头的性能争议

部分 CDN 厂商文档指出过度使用 Vary 会导致边缘节点缓存效率下降。实测数据表明：

  • 单 Vary: Origin 使缓存条目增长 2-5 倍
  • 组合 Vary: Origin, Accept-Language 可能产生指数级增长

解决方案建议：

  1. 使用 Cache-Control: private 限制公共缓存
  2. 对高频变更头（如 User-Agent）进行规范化处理

浏览器实现差异

  • Firefox 83+ 对 Vary: Origin 处理更严格
  • Safari 对预检请求缓存存在历史遗留问题（需通过 Cache-Control: no-store 强制刷新）

未来演进方向

HTTP 工作组正在制定 Client Hints 规范，通过 Accept-CH 头部实现更精细的缓存控制。配合新兴的 Key 头提案，未来可能实现声明式缓存键配置：

http
1Key: ;partition="origin";param=Origin

这将从根本上解决 Vary 头导致的缓存碎片化问题。

总结

正确处理跨域缓存需要开发者深入理解 HTTP 缓存机制与 CORS 规范的交互关系。在安全与性能之间找到平衡点，建议采用 Vary: Origin + 动态 Origin 验证的组合方案，配合监控告警机制确保系统稳定性。随着 Web 平台新特性的发展，持续关注相关标准演进将有助于构建更健壮的前端架构。