启用缓存时仅出现CORS问题的技术求助

核心矛盾梳理 #

你遇到的场景关键差异点：

• 清空浏览器缓存后的首次请求触发CORS错误
• 禁用缓存、禁用后重新启用缓存的请求均正常
• R2仅在请求携带Origin头时返回CORS响应头，且脚本测试新鲜请求、带ETag的缓存请求都能拿到Access-Control-Allow-Origin

可能的原因及排查步骤 #

1. Cloudflare边缘缓存了无CORS头的响应

这是最可能的根源：

• 若之前有不带Origin头的请求（比如爬虫、后端服务的非跨域请求）访问过该R2对象，Cloudflare边缘会缓存这份无CORS响应头的内容
• 当你清空浏览器缓存后首次发起请求，浏览器发送带Origin的跨域请求，但Cloudflare直接返回了边缘缓存的无CORS头响应，导致浏览器触发CORS错误
• 而禁用缓存时，请求直接穿透到R2，R2识别到Origin头返回正确的CORS头；禁用后重新启用缓存，浏览器已缓存了带CORS头的响应，因此正常

排查验证：

• 打开浏览器开发者工具Network面板，清空缓存后发起请求，查看：
  • 请求头是否确实携带Origin
  • 响应头是否缺失Access-Control-Allow-Origin
• 临时在Cloudflare控制台给该R2桶设置Cache Level: Bypass，再清空浏览器缓存测试，若CORS问题消失，即可确认是边缘缓存导致
• 用curl模拟两种请求，验证边缘缓存行为：

  # 模拟不带Origin的请求，触发边缘缓存
  curl -I https://your-r2-bucket-domain/your-object-path
  # 模拟带Origin的跨域请求，查看是否返回缓存的无CORS响应
  curl -I -H "Origin: https://your-frontend-domain" https://your-r2-bucket-domain/your-object-path
  

2. 浏览器首次请求的Origin头未正确携带

虽然脚本测试正常，但浏览器的实际请求可能存在差异：

• 检查浏览器首次请求的请求头，确认Origin是否存在。若缺失，R2不会返回CORS头，直接触发错误
• 可能的原因：浏览器误将R2域名识别为同源（比如CNAME绑定到自有域名但未配置跨域）、fetch请求的mode设置异常（比如设为same-origin）

3. R2 CORS策略的匹配逻辑漏洞

检查R2桶的CORS策略细节：

• 是否仅允许特定HTTP方法？比如你的请求用了GET，但策略里只配置了POST
• 是否对请求头有严格限制？比如AllowedHeaders未包含浏览器自动携带的头（如Accept、Range），导致预请求失败

修复建议 #

• 若确认是边缘缓存问题：在Cloudflare配置缓存规则，针对携带Origin头的请求，设置Cache Level: Bypass，或配置缓存键包含Origin头，确保不同来源的请求缓存独立
• 调整R2的CORS策略，确保所有合法跨域请求都能匹配到规则，比如：

  {
    "CORSRules": [
      {
        "AllowedOrigins": ["*"],
        "AllowedMethods": ["GET", "HEAD"],
        "AllowedHeaders": ["*"],
        "ExposeHeaders": ["ETag"]
      }
    ]
  }
  

内容的提问来源于stack exchange，提问作者Foobar