Cloudflare+Nginx部署ExpressJS与ReactJS时CORS错误排查

所有报错的触发逻辑可以按优先级拆解，从最直接的异常现象往底层配置排查： #

直接触发拦截的前置诱因：请求根本没有走预期的代理链路 #

浏览器观测到请求直接发往http://<server_ip>:8000/api，本身就和跨域配置无关了，问题出在前端请求的地址拼接逻辑：

• 前端项目虽然配置了.env里的CLIENT_URL=/api相对路径，但实际封装请求的代码（axios/fetch的baseURL配置）存在硬编码的旧地址，把之前无域名部署阶段写死的源站IP+8000端口作为了请求地址，完全没有读取最新的环境变量。
• 修改前端环境变量后没有重新执行生产构建，线上跑的静态资源还是旧版本打包产物，自然会沿用旧的硬编码请求规则，根本不会走Nginx反向代理的/api路径。

就算请求链路修正后仍会触发CORS的配置错误 #

等把请求地址修正为走域名下的/api路径，现有配置还是会因为逻辑不匹配触发拦截：

• 从链路设计上，把前端和后端API放到同一个域名路径下，本身属于同源请求，根本不需要额外开启CORS校验，当前引入的CORS配置反而会因为源值不匹配主动拦截合法请求。
• 后端CORS配置的源地址和实际访问协议不匹配：Express里配置的CLIENT_URL=http://my_domain.com是HTTP协议，但Cloudflare已经开启强制HTTPS，用户实际访问的源地址是https://www.my_domain.com，浏览器发送的Origin请求头和后端配置允许的源完全对不上，校验必然失败。
• 后端CORS配置没有覆盖全访问域名变体：Cloudflare同时代理了带www和不带www的两个域名记录，仅在后端配了不带www的HTTP域名，就算协议匹配，带www的访问请求依然会被CORS规则拦截。
• Nginx配置缺失原始协议传递头：现有Nginx规则里没有设置X-Forwarded-Proto头，后端拿到的请求协议始终是和Nginx通信的内部HTTP协议，就算CORS规则放宽，也可能出现源识别错误、重定向循环的连锁问题。

放大问题的Cloudflare配置细节 #

把泛域名记录设置为仅DNS解析模式的状态下，用户浏览器如果之前访问过旧的IP地址接口，会把旧的接口地址存在本地缓存里，持续绕过Cloudflare和Nginx链路直接向源站IP发请求，不管后端CORS怎么配置，都会因为跨域规则不一致被拦截。

• 先通过浏览器开发者工具的源代码定位面板，找到发起异常请求的代码位置，确认是否为硬编码的IP地址，把请求baseURL统一改为相对路径/api，重新执行React生产构建后替换线上静态资源。
• 因为前端本来就部署在同域名下，通过/api路径反向代理到后端，本身不存在跨域需求，可以直接在Express的CORS配置里关闭跨域校验，避免硬编码域名带来的配置不匹配问题。
• 给Nginx的两个location块补充proxy_set_header X-Forwarded-Proto $scheme;，把用户实际请求的HTTPS协议传递给后端服务。
• 清理浏览器本地缓存后重新访问域名，验证请求路径是否符合预期。

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