AWS ALB后部署于Fargate的Express应用出现CORS错误该如何排查

你可能遗漏的配置如下： #

• ALB/安全组拦截OPTIONS预检请求
  浏览器发起非简单请求（比如带自定义头、Content-Type为multipart/form-data的POST请求）时会先发送OPTIONS预检请求，如果你的ALB监听器规则、Fargate实例安全组只允许GET/POST方法，没有放行OPTIONS请求，预检请求会直接被拦截返回错误响应，不会走到Express的CORS中间件，自然不会携带Access-Control-Allow-Origin头。可优先检查ALB、安全组的入站规则，确保OPTIONS方法被放行。
• CORS中间件配置不全
  当前配置仅指定了origin、credentials、methods三个参数，如果你的React请求携带了自定义请求头（比如Authorization、Amplify默认添加的X-Amz-*类头、或者上传场景的自定义头），需要额外配置allowedHeaders参数允许对应的头，否则预检请求会失败，示例配置如下：

  app.use(cors({
      origin: ['*'],
      credentials: false,
      methods: ['GET', 'POST', 'OPTIONS'],
      allowedHeaders: ['Content-Type', 'Authorization', 'X-Amz-Date', 'X-Api-Key', 'X-Amz-Security-Token']
  }));
  

• Express中间件顺序或异常响应未携带CORS头
  如果把cors中间件的注册放在了路由定义、或者其他会提前返回响应的中间件（比如鉴权中间件、静态资源中间件）之后，请求不会走到CORS中间件，不会附加对应响应头。另外如果请求触发了404、500等错误，Express默认的错误响应也不会携带CORS头，可增加全局中间件给所有响应统一加头：

  app.use((req, res, next) => {
    res.header('Access-Control-Allow-Origin', '*');
    res.header('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
    res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
    if (req.method === 'OPTIONS') return res.sendStatus(200);
    next();
  });
  

• 客户端请求配置冲突
  检查React请求是否配置了withCredentials: true，当客户端发起带credentials的请求时，服务端CORS配置的origin不能用通配符*，必须指定明确的源（也就是你的React应用域名https://www.example.com），同时要把服务端的credentials设为true，否则浏览器会直接拦截CORS请求。
• ALB路径重写或路由不匹配
  如果你配置了ALB的路径重写规则，比如把/upload重写成了其他路径，导致Express端匹配不到对应路由返回404，默认的404响应不会携带CORS头，也会触发该错误。可在Express端增加日志打印所有收到的请求方法和路径，确认请求是否正确到达且匹配到了对应路由。

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