iOS Safari蜂窝网络下上传S3遭遇CORS权限问题求助

仅iOS Safari+蜂窝网络触发CORS 400错误，其他环境正常，说明不是基础CORS配置的全局问题，而是iOS Safari在蜂窝网络下的特定行为导致，以下是针对性解决办法：

1. 修正S3 CORS配置的精确匹配问题 #

你的AllowedOrigins里包含带尾斜杠的"https://app.com/"，但报错里的Origin是无尾斜杠的https://app.com，S3的CORS匹配是精确匹配，尾斜杠会导致不匹配。同时iOS Safari在蜂窝网络下可能发送额外隐式头，建议临时放宽Header权限排查：

更新后的CORS配置：

[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "PUT",
            "POST",
            "DELETE",
            "GET",
            "OPTIONS"
        ],
        "AllowedOrigins": [
            "https://app.com"
        ],
        "ExposeHeaders": [
            "ETag"
        ],
        "MaxAgeSeconds": 300
    }
]

排查完成后可再缩小AllowedHeaders范围，添加OPTIONS是为了兼容预检请求。

2. 调整Axios请求头适配iOS Safari行为 #

iOS Safari在蜂窝网络下可能修改请求头变体，手动强制指定关键头，避免浏览器自动生成的不一致：

const response = await axios.put(url, chunk, {
  headers: {
    'Content-Type': 'application/octet-stream',
    'Origin': 'https://app.com' // 强制匹配AllowedOrigins中的域名
  },
  withCredentials: false // S3预签名URL不需要携带凭证，关闭避免额外头
});

去掉手动设置的Cache-Control和Pragma，避免和浏览器默认行为冲突。

3. 检查预签名URL生成逻辑 #

预签名URL的方法、Header、内容必须和实际请求完全匹配，否则会触发400错误，被浏览器误报为CORS问题：

• 生成预签名URL时，务必指定Content-Type为application/octet-stream，和上传请求一致
• 不要在预签名URL中包含未在上传请求中使用的Header，比如Cache-Control

4. 处理蜂窝网络代理/缓存问题 #

部分运营商的蜂窝透明代理会修改请求头或缓存预检请求结果：

• 在请求中添加Cache-Control: no-store（区别于no-cache，彻底禁止代理缓存）
• 确保S3响应的Access-Control-Max-Age设置合理，避免预检请求频繁触发

5. 抓包验证实际请求 #

用Safari开发者工具（需连接Mac调试）抓包，确认预检请求（OPTIONS）的Origin和Access-Control-Request-Headers，对比CORS配置是否匹配：

• 打开Safari开发者菜单→显示Web检查器
• 网络面板筛选OPTIONS请求，查看请求头和响应头
• 若发现未在AllowedHeaders中的头，直接添加到CORS配置中

内容的提问来源于stack exchange，提问作者howdy_miguel