Chrome 90 跨域请求突然失败从原理到实战的完整解决方案最近不少开发者反馈Chrome浏览器升级到90版本后原本正常运行的前端项目突然出现跨域请求失败的问题。控制台只显示一个模糊的strict-origin-when-cross-origin错误让人摸不着头脑。本文将带你深入理解这个新策略的本质并提供一套完整的排查和解决方案。1. 理解strict-origin-when-cross-origin的本质strict-origin-when-cross-origin并非全新的概念而是Chrome团队对默认Referrer Policy的一次重要调整。要真正解决问题我们需要先理解几个关键点Referrer Policy的核心作用是控制浏览器在发送请求时如何携带Referrer信息。这个策略直接影响跨域请求的安全性和隐私保护。Chrome 90版本将默认策略从no-referrer-when-downgrade改为strict-origin-when-cross-origin这一变化带来了三个主要行为同源请求发送完整的URL作为Referrer跨源但安全级别相同(HTTPS→HTTPS)只发送源(协议域名端口)安全级别降级(HTTPS→HTTP)不发送任何Referrer信息注意这个变更主要影响的是Referrer信息的发送方式而非直接导致跨域请求失败。真正的问题往往出现在后端服务对Referrer信息的处理逻辑上。2. 问题诊断从现象到根源的排查流程当遇到跨域请求失败时建议按照以下步骤进行系统排查2.1 检查浏览器开发者工具在Chrome开发者工具的Network面板中重点关注以下几个关键信息请求的Referrer Policy值请求头和响应头的完整内容实际的HTTP状态码不要只看表面显示的200一个典型的异常情况是请求显示200状态码但响应体为空且控制台显示跨域错误。2.2 对比不同环境的表现为了确定问题是浏览器策略变更引起的还是后端配置问题需要进行环境对比测试本地开发环境使用相同Chrome版本访问本地服务生产环境使用相同浏览器访问线上服务不同浏览器使用Firefox或Safari进行对比测试如果问题仅在Chrome 90版本出现基本可以确定是Referrer Policy变更引起的问题。2.3 分析请求流程完整的请求流程可能涉及多个环节需要逐一排查浏览器发送请求时的Referrer信息前端代码中的特殊配置反向代理(Nginx等)的转发规则后端服务的CORS配置安全组或中间件的拦截规则3. 后端解决方案Spring Boot的完整配置对于使用Spring Boot的后端服务需要确保CORS配置正确处理新的Referrer Policy。以下是推荐的完整配置方案Configuration public class WebConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .exposedHeaders(Authorization) .allowCredentials(true) .maxAge(3600); } }关键配置说明allowedOrigins(*)允许所有源访问生产环境应替换为具体的前端域名allowCredentials(true)允许携带凭证(cookie等)exposedHeaders(Authorization)暴露自定义头部给前端maxAge(3600)预检请求缓存时间提示如果使用了Spring Security还需要在安全配置中明确允许OPTIONS方法的预检请求通过。4. Nginx层的关键配置很多时候请求甚至没有到达后端服务就被Nginx拦截了。以下是必须的Nginx配置location /api/ { proxy_pass http://backend-service; # CORS headers add_header Access-Control-Allow-Origin $http_origin; add_header Access-Control-Allow-Credentials true; add_header Access-Control-Allow-Methods GET, POST, PUT, DELETE, OPTIONS; add_header Access-Control-Allow-Headers DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization; # 处理预检请求 if ($request_method OPTIONS) { add_header Access-Control-Max-Age 1728000; add_header Content-Type text/plain; charsetutf-8; add_header Content-Length 0; return 204; } }特别需要注意以下几点Access-Control-Allow-Origin最好使用$http_origin动态设置而不是简单的*当使用凭证(cookie等)时Access-Control-Allow-Origin不能为*必须正确处理OPTIONS方法的预检请求5. 前端适配策略虽然问题主要出在后端配置但前端也可以采取一些措施提高兼容性显式设置Referrer Policymeta namereferrer contentno-referrer-when-downgradeFetch API的特殊处理fetch(url, { credentials: include, referrerPolicy: no-referrer-when-downgrade });axios的全局配置axios.defaults.withCredentials true; axios.defaults.headers.common[Referrer-Policy] no-referrer-when-downgrade;在实际项目中我们遇到过一个典型案例一个运行多年的系统在Chrome自动更新后突然出现跨域问题。经过排查发现后端服务的安全中间件会根据Referrer信息进行额外的安全检查而新的Referrer Policy导致必要的信息缺失触发了拦截机制。最终通过调整中间件的检查逻辑解决了问题。