缓存绕过时CORS头丢失本质是CDN、反向代理或浏览器缓存未透传或覆盖服务端响应头；需禁用缓存验证、检查Response Headers中Access-Control-Allow-Origin是否存在及Vary: Origin是否配置，并在Nginx中使用add_header ... always及proxy_ignore_headers规避缓存污染。
缓存绕过时CORS头丢失，本质是缓存层（CDN、反向代理、浏览器缓存）未正确透传或覆盖了服务端返回的CORS响应头。这不是前端代码问题，而是中间链路把关键安全头“吃掉”了。
确认是否真被缓存层拦截
先排除浏览器本地缓存干扰：在开发者工具 Network 面板中勾选 “Disable cache”，刷新重试。如果此时 CORS 错误消失，说明问题出在缓存环节；如果仍有报错，则回到服务端响应头检查流程。
再查真实响应头来源：点击报错请求 → Headers → 查看 Response Headers 区域。重点确认：
- Access-Control-Allow-Origin 是否存在
- 该字段值是否为预期域名（而非空、null 或被覆盖成 *）
- 是否同时存在 Vary: Origin 头（这是告诉缓存系统：Origin 不同，缓存应区分）
常见缓存层导致CORS头丢失的场景
CDN（如 Cloudflare、阿里云DCDN）默认不缓存带 Vary: Origin 的响应，但若配置了“忽略 Vary 头”或“强制缓存所有 GET 请求”，就会把原本带 CORS 头的响应缓存下来，并在后续不同 Origin 请求中错误复用——此时响应里只剩 Content-Type，CORS 头全无。
Nginx 或其他反向代理若启用了 proxy_cache，且未显式配置 proxy_hide_header 或 proxy_pass_request_headers，也可能因缓存策略漏传响应头。
浏览器自身对 304 Not Modified 响应不做 CORS 头校验——如果服务端返回 304，而上一次 200 响应里没带 CORS 头，浏览器会沿用旧缓存，但不再触发预检，导致静默失败。
验证与修复方法
临时关闭 CDN 缓存或设置“缓存绕过规则”，例如在 Cloudflare 中添加 Page Rule：
- URL 模式填 API 路径（如 /api/*）
- 设置 Cache Level → Bypass
- 同时开启 Origin Cache Control → On
在 Nginx 中确保以下配置存在：
- add_header Access-Control-Allow-Origin "$http_origin" always;（加 always 是关键，否则缓存响应时不生效）
- add_header Vary Origin always;
- 若用 proxy_cache，需加 proxy_ignore_headers Cache-Control Expires Set-Cookie; 避免缓存污染
服务端生成响应时，避免对 OPTIONS 预检请求做缓存：在返回前加 Cache-Control: no-store, must-revalidate，防止代理缓存预检结果并错误复用于后续请求。
