记一次preflight(预检请求)错误排查

起因

今天把网关服务打包 Docker 镜像丢到测试服务器上的时候出来了这么一个问题

定睛一看, CORS

我不都在网关里都配置好跨域了吗

排查

既然是跨域问题,那当然首先确认跨域配置,主要的跨域配置不外乎几个

• Access-Control-Allow-Origin: 用于指定该响应的资源是否被允许与给定的 origin 共享
• Access-Control-Allow-Headers: 用于 preflight request（预检请求）中，列出了将会在正式请求的 Access-Control-Request-Headers 字段中出现的首部信息
• Access-Control-Allow-Methods: 在对 preflight request（预检请求）的应答中明确客户端所要访问的资源允许使用的方法或方法列表

跨域配置确认无误

这时候又回头看看报错, Redirect is not allowed for a preflight request,禁止对预检请求重定向, 看来这次又是新花样啊

既然涉及到了重定向,又是使用的容器化部署,那会不会问题出在 Docker 的虚拟网卡配置上呢,虽然这个几率很小,但是试试无妨

于是查了 Docker 几种网络模式

• bridge模式: 默认模式,使用 –net=bridge 指定,此模式会为每一个容器分配Network Namespace、设置IP等，并将并将一个主机上的Docker容器连接到一个虚拟网桥上,可以理解为加了一块虚拟网卡
• host模式: 使用 –net=host 指定,启动容器的时候使用host模式，这个容器将不会获得一个独立的Network Namespace，而是和宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡，配置自己的IP等，而是使用宿主机的IP和端口
• none模式: 使用 –net=none 指定,Docker容器拥有自己的Network Namespace，但是，并不为Docker容器进行任何网络配置。也就是说，这个Docker容器没有网卡、IP、路由等信息。需要我们自己为Docker容器添加网卡、配置IP等。
• container模式：使用 –net=container:NAME or ID 指定,这个模式指定新创建的容器和已经存在的一个容器共享一个 Network Namespace ，而不是和宿主机共享。新创建的容器不会创建自己的网卡，配置自己的IP，而是和一个指定的容器共享IP、端口范围等。同样，两个容器除了网络方面，其他的如文件系统、进程列表等还是隔离的。两个容器的进程可以通过 lo 网卡设备通信。

使用host模式创建容器,无果,基本上排除容器网络问题了,为了确保万无一失,使用jar包进行部署,结果还是一样

绝望之中,打开了 firefox ,看到了一贫如洗的控制台

等等,重定向,firefox, Chrome,我明白了什么,天杀的Chrome
罪魁祸首就是Chrome在 90 版本加入的新(sha bi)特性,默认使用HTTPS

禁止 Chrome 强制 http 转向 https

1. 在地址栏输入 chrome://net-internals/#hsts
2. 在最底下 Delete domain security policies 输入域名并点击 delete
3. 在 Query HSTS/PKP domain 输入域名并 query,查询不到即成功删除

最终