Preflight OPTIONS请求返回403禁止及浏览器跨域请求异常问题

我之前开发跨域应用时也碰到过完全一样的问题，尤其是用Content-Type: application/json的POST请求时，Chrome的预请求总是卡壳。结合你的场景（localhost测试+后续部署到公司域名），给你几个实用的解决思路：

核心原因先理清楚 #

当你从localhost发送带JSON请求体的POST请求时，浏览器会先触发OPTIONS预请求，用来确认后端是否允许这个跨域操作。如果后端的CORS配置没覆盖到OPTIONS请求，或者权限校验误拦截了它，就会返回403；同时如果OPTIONS的响应头和实际请求的响应头不一致，也会触发浏览器的跨域安全报错。

针对性解决方案 #

1. 修复后端CORS配置（最根本的解决办法） #

你需要让后端明确处理OPTIONS请求，返回正确的响应头，并且跳过OPTIONS的权限校验（因为预请求不会携带认证信息，比如token）：

• 必须返回的响应头：
  • Access-Control-Allow-Origin: 测试阶段可以设为http://localhost:你的端口（别用*如果请求带认证信息），正式环境换成公司的官方域名
  • Access-Control-Allow-Methods: 至少包含OPTIONS, POST, GET，加上你用到的其他HTTP方法（PUT、DELETE等）
  • Access-Control-Allow-Headers: 必须包含Content-Type，如果你的请求带了其他自定义头也要加上
• 举个简单的例子（Node.js/Express环境）：

  const cors = require('cors');
  app.use(cors({
    origin: 'http://localhost:3000', // 替换成你的前端端口
    methods: ['OPTIONS', 'GET', 'POST'],
    allowedHeaders: ['Content-Type', 'Authorization']
  }));
  // 确保OPTIONS请求直接返回200
  app.options('*', cors());
  

• 注意：很多后端框架会默认把OPTIONS请求纳入权限校验逻辑，你需要单独配置跳过OPTIONS的认证检查，比如Spring Boot里可以写一个过滤器专门处理OPTIONS请求，直接返回允许的头。

2. 开发测试阶段的临时绕过方案 #

如果后端暂时没法调整，你可以用Chrome的开发模式绕过跨域校验：

• 关闭所有Chrome窗口，然后用命令行启动：

  chrome.exe --disable-web-security --user-data-dir=C:\Temp\ChromeDevSession # Windows
  # 或者Mac
  open -a Google\ Chrome --args --disable-web-security --user-data-dir=/tmp/ChromeDevSession
  

• 或者用代理工具把前端请求转发到后端，比如Webpack Dev Server的proxy配置，这样请求就变成同域的了，不会触发预请求：

  // webpack.config.js
  module.exports = {
    devServer: {
      proxy: {
        '/api': {
          target: 'https://你的后端API地址',
          changeOrigin: true
        }
      }
    }
  };
  

3. 正式部署前的预校验 #

当你部署到公司官方域名后，只要前端和后端同域，或者后端配置允许该域名的跨域请求，预请求的问题就会自然消失。建议提前在测试环境模拟正式域名的请求，验证CORS配置是否正确，避免上线后踩坑。

额外注意事项 #

• 不要在生产环境使用Access-Control-Allow-Origin: *，如果你的请求携带了Cookie或Authorization头，必须指定具体的域名，否则浏览器会拒绝接受响应。
• 确保OPTIONS请求的响应头和实际请求的响应头保持一致，尤其是Access-Control-Allow-Origin字段，不能出现时而允许localhost时而允许其他域名的情况。

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