API接入SCDN后只有OPTIONS失败：把预检与业务请求分开排查

接口在命令行工具里能返回结果，网页却提示跨域错误，源站还查不到POST记录，这时应先看浏览器是否发出了OPTIONS预检。实际业务请求可能根本没有开始，继续调业务参数无法解决前一阶段的失败。

预检询问的内容与业务操作不同

Fetch规范定义，CORS预检使用OPTIONS，表达后续请求准备采用的方法和请求头；跨域预检不携带业务请求所用的凭据。因此不能要求预检先通过依赖会话Cookie的登录流程。

允许符合条件的预检，不等于允许匿名执行实际操作。真正的业务请求仍要执行身份认证、对象授权和输入检查，两阶段应分别设计和验证。

从一条失败请求建立记录

只记录头部名称和必要的非敏感值，不把实际访问令牌复制到排障材料。测试URL要与网页使用的地址完全一致，避免拿另一个环境的结果做证明。

检查是哪一层提前返回

先在边缘日志查OPTIONS的处理动作，再看代理与应用是否收到。如果边缘返回需要执行JavaScript的挑战页面，浏览器不会把它当成正常的预检许可。若代理将请求转到登录页，也应回到预检的职责重新配置。

规则应限定到实际需要的API路径和允许来源，核对方法及请求头集合。不要为了一个接口全站放行OPTIONS，也不要把任意Origin原样返回后就认为安全。业务页面、第三方集成和管理界面的来源通常需要分别登记。

不要忽略预检结果缓存

浏览器有独立的CORS预检缓存，Access-Control-Max-Age参与控制相关许可信息的保留。它与CDN缓存业务响应不是同一件事。因此修改服务端策略后，旧浏览器状态与新会话可能表现不同。

验证时记录浏览器环境和请求条件，分别观察首次请求与后续请求。不要把“第二次没看到OPTIONS”直接判成规则失效，也不要只用一个已经成功预检的会话验证刚修改的策略。

用正反两组业务结果收尾

允许来源应能完成预检和合法操作；不允许来源不应取得对应跨域许可。与此同时，无凭据或无对象权限的实际请求仍应被业务服务拒绝。CORS限制浏览器读取行为，不能替代服务端访问控制。

把两阶段记录交给SCDN实施团队，可以更快定位到具体规则。上线后还应观察允许来源的变更流程，避免前端换域名时临时扩大许可范围且长期不回收。

资料核对日期：2026年10月30日。本文由AI辅助整理，技术事实依据文内原始资料核对。示例与操作清单供实施参考；产品配置和软件维护状态以实施时的官方资料为准。