本文由 国内云代理商『聚搜云 JuSouYunClouD -服务器服务商•撰写』如需转载请注明！
阿里云OSS跨域请求失败CORS配置方法
前端从业务域名加载 OSS 文件时，控制台突然报出 No 'Access-Control-Allow-Origin' header，请求被浏览器拦截。这个现象基本可以直接归类为 OSS跨域请求失败CORS配置 问题，优先检查 Bucket 的 CORS 规则，而不是先怀疑签名或网络。很多开发在错误方向上排查了权限和 CDN，最后才发现规则漏配了 OPTIONS。
认识OSS跨域请求与CORS规则
为什么前端访问OSS资源会被浏览器拦截？
浏览器同源策略要求协议、域名、端口完全一致，https://app.example.com 去请求 https://bucket.oss-cn-hangzhou.aliyuncs.com/file 显然不同源。OSS Bucket 默认不返回 Access-Control-Allow-Origin 响应头，因此即使请求到达 OSS 并返回 200，浏览器也会把响应体丢掉，前端拿到的是网络错误或 CORS 报错。这个拦截发生在浏览器侧，不是 OSS 拒绝了请求。
CORS规则在OSS侧到底放行了什么？
OSS 的 CORS 规则是在响应预检请求和实际请求时补充对应响应头，放行指定的 Origin、Method 和 Header。规则按顺序匹配，首个命中生效，不会合并后续规则。从武汉阿里云代理商聚搜云整理的运维案例来看，多数“配置了还报错”的情况是只勾了 GET，漏掉 OPTIONS，导致浏览器 preflight 请求返回 403，前端看到的是 CORS preflight 失败，而不是文件加载失败。
分析OSS跨域失败的原因
多数 OSS 跨域请求失败不是配置项漏填，而是没有理解 Bucket 默认限制、浏览器拦截条件以及哪些请求会触发预检。下面拆开看。
默认限制有哪些
OSS 的 Bucket 默认不开放任何跨域访问，响应头里不会出现 Access-Control-Allow-Origin，这是强制安全基线，不是功能缺失。CORS 规则是 Bucket 级别的，可以按前缀匹配，但不能只针对单个 Object 放行。规则按顺序匹配，首个命中的规则生效，不会把后面规则的 Method 和 Header 合并。从武汉阿里云代理商聚搜云处理过的工单来看，不少失败案例正是误以为多条规则会取并集，第一条规则范围过窄，后续规则根本没参与匹配。
浏览器如何拦截
浏览器拦截发生在响应阶段，OSS 即使返回了数据，响应头不满足条件也会被浏览器丢弃。判断标准是响应头里有没有匹配的 Access-Control-Allow-Origin。如果请求方法为 PUT/DELETE，或者携带 Authorization、Content-Type: application/json，浏览器会先发 OPTIONS 预检请求，要求 OSS 明确返回允许的方法和请求头。这里有个高频坑：Origin 配成 * 的同时携带 Authorization，浏览器会认为这是带凭证的跨域请求，直接拒绝，OSS 的 CORS 响应头不会生效。
哪些请求受影响
axios/fetch 里带自定义头或 JSON 内容类型的请求最容易触发预检，这类请求不是简单请求。如果 CORS 规则只勾选 GET，预检 OPTIONS 会返回 403，后面的 PUT 或 DELETE 根本不会发出去。使用 img 标签加载图片虽然不受 CORS 限制，但无法通过脚本读取内容。另外浏览器缓存和 CDN 缓存会让旧规则继续生效一段时间，改完配置后需要无痕窗口测试，或用 curl 模拟预检请求确认响应头。
配置CORS前的准备工作
在处理 OSS 跨域请求失败 CORS 配置时，先别急着在控制台里勾规则。CORS 是 Bucket 级安全边界，默认不配置时浏览器必然拦截，但配置后仍失败，多数是因为没有先确认浏览器实际发出的 Origin、Method 和 Access-Control-Request-Headers。从武汉阿里云代理商聚搜云接触到的企业运维场景来看，这类问题里很大一部分是配置前漏看了请求头，把预检请求当成“浏览器的怪请求”忽略掉了。建议先用开发者工具 Network 面板抓一次失败请求，记录三项关键信息，再回控制台填规则。
一、确认访问来源和请求方法，不要用 * 偷懒
Allowed Origin 写 * 只适合完全公开的静态资源读取。一旦前端携带 Authorization，比如 STS 临时凭证或签名 URL，* 会与凭证请求互斥，浏览器照样拦截，响应头里不会出现 Access-Control-Allow-Origin。生产环境应精确填写实际域名，例如 https://console.example.com，多域名拆成多条规则。方法层面，只读场景通常放行 GET 和 HEAD 即可，不需要 PUT、DELETE，规则越宽，越容易因为顺序匹配意外放行。
二、准备阿里云账号权限前，先确认 Bucket 归属和授权边界
配置 CORS 需要 oss:PutBucketCORS 权限，子账号或 STS 临时凭证只有 oss:GetObject 时，控制台能看到 Bucket 却保存失败，这是权限不足的典型表现。还要确认当前 Bucket 是否被 Bucket Policy 或 RAM Policy 叠加了 Deny 规则。另一个常见误区是，CORS 只作用于单个 Bucket，不自带跨 Bucket 继承；如果前端走了自定义域名或 CDN，还要检查 CDN 是否透传 Origin 和 Access-Control-Request-Headers，否则 OSS 配置正确，跨域失败仍可能被 CDN 层放大。
三、预检请求和缓存是配置前最容易忽略的变量
OPTIONS 预检是跨域失败的高发点。只要请求方法是 PUT、DELETE，或携带 Content-Type: application/json、Authorization，浏览器会先发 OPTIONS 询问 OSS。配置时必须勾选 OPTIONS 并放行对应头。完成配置后，先用 curl -i -X OPTIONS -H "Origin: https://yourdomain.com" -H "Access-Control-Request-Method: GET" https://bucket.oss-cn-hangzhou.aliyuncs.com/file 验证响应中是否有 Access-Control-Allow-Origin。curl 正常但浏览器仍报错时，先开无痕窗口排除缓存；接了 CDN 的还要刷新缓存，别把生效延迟误判为配置无效。
在OSS控制台配置CORS
进入阿里云OSS控制台后，选择目标Bucket，在左侧导航栏进入“数据安全 > 跨域设置”。控制台默认没有任何CORS规则，浏览器会拦截所有跨域资源请求。从武汉阿里云代理商聚搜云整理的运维案例来看，相当一部分“配置后仍失败”并不是规则没写对，而是配置前没有采集浏览器真实发出的Origin、Method和Access-Control-Request-Headers，导致规则与请求不完全匹配。因此第一步不是急着创建规则，而是先在浏览器开发者工具的Network面板里确认这三项内容。
进入控制台步骤
登录阿里云控制台，进入对象存储OSS的Bucket列表，选择目标Bucket，在左侧菜单找到“数据安全 > 跨域设置”。如果Bucket绑定了CDN，还要确认CDN是否回源到OSS并透传响应头，否则浏览器访问CDN域名时可能看不到OSS返回的CORS头。进入跨域设置页面后，先查看已有规则，默认通常为空。点击“创建规则”之前，建议在浏览器中触发一次失败请求，记录请求头里的Origin、Request Method以及预检请求中的Access-Control-Request-Headers，这是后续配置能否一次命中的关键。
添加CORS规则
创建规则时，来源不能图省事直接填 *，尤其是前端使用STS临时凭证或携带Authorization头时，* 与凭证不能同时生效。生产环境应将Allowed Origin精确填写为实际域名，比如 https://console.example.com，多域名就添加多条规则。允许Methods至少包含GET，如果涉及上传、删除则要勾选PUT、DELETE，同时必须勾选OPTIONS用于响应预检请求。允许Headers要包含前端实际携带的头，常见需要显式加入Content-Type、Authorization以及OSS STS场景下的x-oss-security-token。规则顺序同样重要，OSS按顺序匹配，首个匹配即生效，不是合并多条规则，因此不要先放一条宽泛的 * 规则再放精确规则，这样精确规则可能永远不生效。
应用并验证
保存规则后，OSS配置通常数秒到几分钟内生效，但浏览器可能缓存预检结果，验证时建议使用无痕窗口或强制刷新。命令行验证可以直接模拟预检请求：
curl -I -X OPTIONS \
-H "Origin: https://console.example.com" \
-H "Access-Control-Request-Method: PUT" \
-H "Access-Control-Request-Headers: Authorization,Content-Type" \
https://bucket.oss-cn-hangzhou.aliyuncs.com/object
如果响应里没有出现 Access-Control-Allow-Origin、Access-Control-Allow-Methods 和 Access-Control-Allow-Headers，优先检查规则顺序、Origin是否多写斜杠或端口不一致，再确认是否被CDN缓存了旧的响应头。反复修改规则不如先用一条精确规则验证通过，再扩展其他域名和方法。
常见配置错误排查
跨域配置失败时，第一步不是增加更多规则，而是回到规则列表检查顺序。从武汉阿里云代理商聚搜云整理的运维案例来看，这类问题很少是OSS能力限制，多数是因为第一条规则拦住请求，或者Origin匹配不完整。下面按三个方向排查。
检查规则顺序
OSS的CORS规则按列表从上到下匹配，命中即停止，不会合并多条规则。如果第一条是 Allowed Origin: *，后面再写精确域名也无效，带 Authorization 的请求会被第一条通配规则处理，浏览器最终报 No 'Access-Control-Allow-Origin' header。排查时先把精确域名规则置顶，并在同一条规则中勾选 OPTIONS 方法和 Authorization 头。用 curl 模拟预检可快速判断：curl -i -X OPTIONS "https://bucket.oss-cn-hangzhou.aliyuncs.com/file" -H "Origin: https://www.example.com" -H "Access-Control-Request-Method: PUT" -H "Access-Control-Request-Headers: Authorization"。响应中出现 Access-Control-Allow-Origin: * 且请求带凭证时，浏览器仍会拦截，这是规则顺序导致的典型误判。
核对源头匹配
Origin 的协议、域名、端口必须与浏览器请求完全一致，http 和 https 不同，www.example.com 和 example.com 也不等价。不少失败是因为规则里填的域名与实际请求差一个子域或协议。生产环境不建议用 *，尤其在 STS 临时凭证或签名 URL 场景下，* 与 Authorization 不能同时生效。多域名应拆成多条规则，每条写完整 Origin。排查时打开浏览器 Network 面板，查看预检请求的 Origin 和 Access-Control-Request-Headers，逐项对照控制台规则。
使用工具测试
配置完成后不要只按 F5，浏览器缓存、CDN 缓存都会影响验证。可在无痕窗口或命令行测试：curl -s -D - -o /dev/null -X OPTIONS "https://bucket.oss-cn-hangzhou.aliyuncs.com/file" -H "Origin: https://www.example.com" -H "Access-Control-Request-Method: GET"，重点看 Access-Control-Allow-Origin 是否与 Origin 完全一致，以及 Access-Control-Allow-Methods 是否包含实际方法。若走了 CDN，还要确认 CDN 是否透传 Origin 和 Access-Control-Request-Headers 头，部分 CDN 会重写或剥离跨域头。武汉阿里云代理商在远程排查时通常也会先让用户执行这个 curl 命令确认响应头，而不是直接改控制台。
武汉代理商技术支持
武汉阿里云代理商在处理 OSS 跨域请求失败时，常见问题不是用户完全不会配置，而是规则顺序、请求头和缓存三类原因叠加，导致控制台看起来已经配置正确，浏览器仍报 No 'Access-Control-Allow-Origin' header。以下从配置代查、远程排查和持续运维三个角度说明。
提供配置服务
从武汉阿里云代理商聚搜云接触到的企业运维场景来看，CORS 配置出错集中在三类：Allowed Origin 填 * 却携带 Authorization、未放行 OPTIONS 预检、规则顺序把宽泛项放在前面导致首个匹配命中错误。配置前应先用浏览器 Network 面板抓取 Origin、Method 和 Access-Control-Request-Headers，再按实际域名精确配置，避免直接全选所有方法。
专家协助处理
远程排查时，先让用户在无痕窗口或 Ctrl+F5 强刷下复现，排除浏览器和 CDN 缓存影响。再用 curl -H "Origin: https://example.com" -H "Access-Control-Request-Method: PUT" -X OPTIONS -i https://bucket.oss-cn-hangzhou.aliyuncs.com/file 模拟预检，查看响应是否包含 Access-Control-Allow-Origin 和 Access-Control-Allow-Headers。如果缺少对应头，即可判断是 OSS 规则未命中或 Header 未勾选，而不是前端代码问题。
售后运维支持
后续不建议“先全开、上线再收紧”。武汉阿里云代理商通常建议按环境拆分 Bucket 或目录前缀，例如 dev/、test/、prod/ 分别配置来源与方法；生产环境 Allowed Origin 固定为正式域名，STS 临时凭证请求明确放行 Authorization 而不使用 *。聚搜云在整理这类故障时发现，规则越具体，后续定位跨域失败链路越短，也能减少误放行风险。
