Chrome跨域报错：Access-Control-Allow-Origin值与请求源不匹配

这个CORS拦截和9005端口的配置没关系，核心问题是跨域请求触发跨源302重定向时，浏览器不会继承原请求地址的CORS配置，会对重定向后的目标地址单独做完整CORS预检校验——你只给9005配了CORS规则，完全漏了重定向目标9006端口的CORS响应头配置。

你看到的报错提示是Chrome 102版本的已知误导性提示：跨域重定向预检失败时，浏览器会错误抛出Access-Control-Allow-Origin值与提供的源不匹配的错误，实际从你贴的报文就能看出来，发往9006的请求只显示Provisional headers are shown，说明浏览器发往9006的OPTIONS预检请求根本没拿到符合要求的响应，不是真的返回的Allow-Origin值写错了。

记住同源判定规则：哪怕主机都是localhost，只要端口不同（8888/9005/9006）就属于完全独立的源，CORS配置各源独立生效，前一个地址的CORS配置不会沿用到重定向后的地址。

给9006端口的服务配置CORS规则即可，因为你的请求开了credentials: 'include'还带了自定义Authorization头，配置必须满足以下硬要求，少一个都不行：

• 对OPTIONS预检请求返回200或204状态码
• Access-Control-Allow-Origin 绝对不能用通配符*，必须明确写https://localhost:8888
• 必须返回Access-Control-Allow-Credentials: true
• Access-Control-Allow-Headers 要包含Authorization，以及请求里实际携带的其他自定义头
• Access-Control-Allow-Methods 要包含GET方法

不想给9006配CORS也可以，直接调整登录流程绕开跨域重定向：

• 改9005的/_login接口，别返回302，直接把生成的TOKEN放在响应体里返回给前端
• 前端拿到TOKEN后自己拼9006的地址跳转，或者主动带TOKEN请求9006就行

配完重新发请求，抓包看9006对OPTIONS预检请求的响应，确认上面列的几个CORS头都正确返回，拦截就会消失。

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