流量切换后跨域报错本质是请求路径、源站角色或响应链路变化导致原有cors配置失效；需排查域名/协议变更、中间件未透传响应头、预检请求未处理、衍生资源未同步配置及cdn缓存未更新五类问题。
流量切换后出现跨域 CORS 报错，本质不是“新接口出问题”，而是**请求路径、源站角色或响应链路发生了变化**，导致原本隐性合规的跨域配置突然暴露缺陷。排查要聚焦“变在哪里”——是域名变了？协议升级了？CDN 节点换了？还是后端服务路由逻辑调整了？下面分四类关键场景直接给出排查动作。
确认当前请求的实际目标地址和来源 Origin
打开浏览器开发者工具 → Network 标签页 → 找到报错的请求 → 点击查看详情：
- 看 Request URL：是否从
https://api.old.com切到了https://api.new.com或https://cdn.example.com？域名变更意味着跨域策略必须重新对齐； - 看 Origin 请求头（在 Headers → Request Headers 中）：是否仍是
http://localhost:3000？还是变成了https://prod.example.com？生产环境上线常因未更新allowedOrigins白名单而失败； - 特别注意协议变化：比如从
http://切到https://，哪怕域名相同，也构成跨域，且 HTTPS 页面无法加载 HTTP 资源（混合内容拦截），会先于 CORS 报错触发更底层的拒绝。
检查新链路上每一层是否都透传/添加了 CORS 响应头
流量切换往往引入新组件（如 API 网关、WAF、CDN、反向代理），它们可能默认不转发或覆盖响应头：
- 用
curl -I https://your-api-endpoint直连新地址，确认响应中包含Access-Control-Allow-Origin； - 如果直连正常，但浏览器仍报错 → 说明中间层（如 Nginx、Cloudflare、阿里云 WAF）未配置跨域头，或配置被缓存覆盖；
- 重点查
OPTIONS预检请求：切换后若新增了自定义 Header（如X-Trace-ID）或改用PUT/DELETE方法，会触发预检，而很多网关默认不处理OPTIONS，需显式放行并返回完整 CORS 头。
验证 TS 分片、密钥、子索引等衍生资源是否同步适配
如果是 HLS 流媒体类业务，流量切换常伴随 CDN 域名或存储路径变更，但开发容易只测 M3U8 主索引：
- 在 Network 面板中搜索
.ts、.key、.m3u8（子索引），逐个点击检查响应头 —— 每一个资源都必须带Access-Control-Allow-Origin； - 常见坑：新 CDN 域名（如
stream-new.cdn.com）未配置跨域规则，而旧域名（stream-old.cdn.com）已配好； - 密钥接口（
#EXT-X-KEY: URI="https://auth.example.com/key"）若指向独立鉴权服务，该服务也必须单独配置 CORS，不能依赖主 API 的配置。
排除 CDN 缓存与节点配置不一致问题
流量切到新 CDN 或新集群后，缓存和配置同步延迟是高频根因：
- 用不同地区 IP（如北京、广州、海外）访问，看是否仅部分用户报错 → 指向 CDN 边缘节点配置未全量生效；
- 清除 CDN 缓存（尤其是
OPTIONS和GET请求的缓存键），避免旧响应（无 CORS 头）被长期缓存； - 检查 CDN 控制台 CORS 配置是否开启，有些平台（如 Cloudflare）需在「Rules」中单独启用「CORS Header」功能，而非仅靠源站返回。
