部署于Google Cloud的Spring Boot API（调度文件配置自定义域名）随机CORS问题求助

• 检查负载均衡/调度配置的CORS规则一致性
  随机问题大概率和多实例、调度规则不一致有关。去Google Cloud控制台检查负载均衡（如果用了）或者调度文件里的CORS配置，确保所有路由实例的CORS策略完全统一——包括允许的Origin、请求方法、请求头，尤其是动态Origin配置时的匹配逻辑不能有遗漏。要是部分实例的规则没更新，就会随机触发失败。

• 统一Spring Boot应用的CORS配置
  确认应用代码里的CORS配置（比如@CrossOrigin注解或全局配置）和Google Cloud层面的规则没有冲突。两端都配CORS很容易因为优先级或规则叠加出问题，建议只在一个层面配置（要么Cloud侧，要么应用内部）。比如全局配置示例：

  @Configuration
  public class CorsConfig {
      @Bean
      public WebMvcConfigurer corsConfigurer() {
          return new WebMvcConfigurer() {
              @Override
              public void addCorsMappings(CorsRegistry registry) {
                  registry.addMapping("/domain/**")
                          .allowedOrigins("https://your-custom-domain.com")
                          .allowedMethods("GET", "POST", "OPTIONS")
                          .allowedHeaders("*")
                          .allowCredentials(true);
              }
          };
      }
  }
  

• 排查缓存导致的响应不一致
  检查是否开了HTTP缓存（比如Cloud CDN或应用内部缓存），如果CORS响应头被缓存，当缓存的响应头和当前请求的Origin不匹配时就会失败。要确保Access-Control-Allow-Origin这类CORS头不被缓存，或者缓存策略按Origin区分。比如在Google Cloud CDN里把Origin加入缓存键，或者直接禁用CORS响应头的缓存。

• 确认实例版本一致性
  如果上周做过应用更新或滚动部署，可能存在新旧实例混跑的情况，部分实例的CORS配置没同步。去控制台看所有运行的应用实例版本，确保所有实例的代码、配置完全一致。

• 捕获失败请求的详细信息
  下次CORS失败时，用浏览器开发者工具的Network面板，记录下失败请求的响应头、请求Origin，还有具体错误提示（比如Origin不被允许，或者Credentials配置问题）。这些信息能精准定位问题——比如是不是偶尔请求的Origin带了端口或子域名变化，或者响应头里的CORS字段时有时无。

• 验证自定义域名的SSL配置
  检查自定义域名的SSL证书是否完整有效，有没有部分实例或路由用了未信任的证书，导致浏览器触发安全限制，间接表现为CORS错误。去Google Cloud控制台确认SSL证书状态，确保覆盖所有关联域名，且未过期。

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