Hapi/Joi+FormData文件上传场景下偶发CORS错误问题求助

优先排查AWS WAF/CloudFront规则 #

• 你看到的CORS报错只是表象，本质是Chrome/Edge发送的预检请求或者实际上传请求被AWS边缘层拦截了，服务端没机会返回正确的CORS头。特定文件触发拦截的核心原因大概率是文件内容匹配到了AWS WAF默认规则的拦截特征：比如未压缩的图片、未删减字体的PDF里可能存在类似SQL注入、XSS的特征字符串，或是自定义规则误判了文件二进制内容。
  • 验证方法：在AWS控制台查看对应API的WAF日志、CloudFront访问日志，搜索失败请求的请求ID，确认是否被WAF规则命中拦截。
  • 修复方案：调整WAF规则优先级，给文件上传接口添加规则例外，放行multipart/form-data类型POST请求的二进制内容匹配校验。

补全CORS逻辑缺失项 #

• 你现有的预检逻辑漏了Access-Control-Allow-Origin头的返回，这是CORS校验的必填项。之前能正常运行是因为普通请求没有触发特殊拦截，一旦请求被边缘层提前返回，缺失的头就会直接触发CORS报错。
  • 修复方案：在预检逻辑里添加如下代码：

  if (request.headers['origin']) {
    response.headers['access-control-allow-origin'] = request.headers['origin'];
    response.headers['access-control-allow-credentials'] = 'true';
  }
  

校验FormData请求头处理逻辑 #

• Chrome/Edge在发送带文件的FormData请求时，会自动生成Content-Type: multipart/form-data; boundary=xxx头，部分反向代理会对过长的boundary值或者携带特殊字符的boundary做拦截。
  • 验证方法：打开Chrome控制台网络面板，对比成功和失败请求的Content-Type头boundary值差异，看失败请求的boundary是否存在特殊字符或者长度超标。
  • 修复方案：如果使用了Nginx/CloudFront等反向代理，调整client_max_body_size、proxy_buffer_size等参数，避免请求头或者请求体被截断。

快速验证方法 #

• 拿一个必现失败的文件，用Postman直接调用线上接口跳过浏览器CORS校验，看是否能上传成功：如果Postman也失败，100%是服务端/边缘层的拦截问题；如果Postman成功，再回头排查CORS头和浏览器请求逻辑即可。

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