页面能打开，接口却在浏览器里报跨域错误，问题不一定出在源站。排查边缘节点配置CORS跨域响应头的常见问题，应从浏览器实际收到的响应入手：核对请求的 Origin、OPTIONS 预检、缓存行为，再检查回源和错误响应。
先确认浏览器要求什么
CORS由浏览器执行。假设页面来自 https://app.example.test，接口位于 https://api.example.test，两者主机名不同，属于跨源请求。Origin由协议、主机名和端口组成；配置时要按实际来源匹配，不能只看域名是否相似。
打开浏览器开发者工具的 Network 面板，选中失败请求，分别查看 Request Headers 和 Response Headers。记录 Origin、请求方法、Access-Control-Request-Method，以及是否有 Access-Control-Request-Headers。不要只看控制台报错文字：预检失败和实际接口响应缺少跨域头，修复位置可能不同。
按请求阶段核对边缘配置
实际响应：来源与凭证
Access-Control-Allow-Origin应返回请求方允许的来源，或在适用条件下返回通配符。若请求需要浏览器携带 Cookie 或授权凭证，响应还须设置Access-Control-Allow-Credentials: true，并返回明确的来源；不能把通配符与凭证许可组合使用。允许来源列表应采用完整的协议、主机名和端口匹配，避免用宽松的字符串包含规则误放其他站点。
预检响应：方法与请求头
浏览器为非简单请求发送OPTIONS预检。边缘节点若拦截OPTIONS、将其转发到不接受该方法的源站，或没有返回所需字段，浏览器就不会继续发送实际请求。检查Access-Control-Allow-Methods是否包含实际方法，Access-Control-Allow-Headers是否覆盖浏览器请求的自定义头；字段名大小写通常不敏感，但名称必须对应。
缓存、重复响应头和错误状态也要查
如果边缘规则按来源动态返回Access-Control-Allow-Origin，却缓存了未区分来源的响应，后来的请求可能拿到另一来源对应的头。此时应让缓存键考虑Origin，或在缓存策略中正确处理变化；同时根据响应策略设置Vary: Origin，提示共享缓存响应会随来源变化。具体配置取决于边缘产品的缓存规则，不能仅添加Vary就假定缓存键已经改变。
还要检查源站和边缘规则是否同时添加Access-Control-Allow-Origin。重复字段可能被浏览器视为无效；应确定由哪一层统一生成。部分平台仅在成功响应上加头，导致401、403、404或5xx页面仍被浏览器报为跨域错误。需要检查这些状态的响应规则，但不应因此向任意来源开放敏感接口。
可执行的排查顺序
- 在浏览器 Network 面板确认失败的是OPTIONS预检还是实际请求，并抄下请求中的Origin、方法和请求头。
- 在边缘配置中核对来源匹配、允许的方法、允许的请求头，以及凭证设置是否彼此兼容。
- 分别检查OPTIONS和实际请求的响应头，并比较200与常见错误状态；确认相关头没有缺失或重复。
- 清除或绕过相关缓存后，用两个不同来源重复验证。若响应随Origin变化，再核对缓存键和Vary: Origin设置。
- 若边缘返回值仍不符，沿回源链路检查源站响应，并确认边缘规则是否覆盖、追加或改写了源站的跨域头。
这套顺序适用于静态站点调用独立API、浏览器上传文件等常见场景。定位边缘节点配置CORS跨域响应头的常见问题时，关键是对照同一请求的请求头、边缘响应和缓存状态，而不是仅凭源站配置推断浏览器最终收到的内容。
常见问题
为什么curl能请求成功，浏览器却报跨域？
curl不会像浏览器那样执行CORS检查。请求成功只说明服务端返回了响应，不能证明响应头满足浏览器的跨域规则。
预检通过，实际请求仍失败怎么办？
单独查看实际响应的状态码和跨域头。预检许可不等于实际响应自动带有相同字段，边缘规则可能只处理了OPTIONS。
修改配置后为什么仍看到旧结果？
可能命中了边缘缓存或浏览器缓存。先确认响应是否来自缓存，再按平台规则清理对应对象或等待缓存更新，并重新检查响应头。
先分清预检与实际响应，再查来源、凭证、缓存和错误状态，通常比反复改规则更有效。遇到边缘节点配置CORS跨域响应头的常见问题，最终以浏览器实际收到的响应为准。
