Cloud Run返回无CORS头的429错误致浏览器拦截问题求助

我们通过Terraform部署了Cloud Run上的Angular前端应用和NestJS后端API。当请求激增触发Cloud Run扩容时，GCP会直接返回429错误（并非API自身抛出），但这些错误响应未携带任何CORS头。浏览器因缺少ACCESS-CONTROL-ALLOW-ORIGIN头拦截响应，导致Angular内置的错误重试机制无法识别429状态码，完全失效。

扩容场景细节：实例从1个扩容到5个时，每秒约有58个请求，其中14个请求未到达API实例就被拦截，日志显示请求延迟为0ms——说明GCP没有等待新实例启动就绪就直接拒绝了请求。

当前基础设施配置：

• Cloud Run实例
  • api（NestJS）容器配置：

    容器设置	配置值
    CPU分配模式	仅请求处理时分配CPU
    启动CPU加速	禁用
    并发数	80
    请求超时	120秒
    执行环境	第一代（默认）
    最小实例数	1
    最大实例数	5

  • web-app（Angular）前端应用
• Serverless区域网络端点组（NEG）
  • api-neg：关联api服务
  • web-app-neg：关联web-app服务
• 经典外部应用负载均衡器
  • 后端服务：load-balancer-backend-api关联api-neg，load-balancer-backend-web-app关联web-app-neg
  • UrlMap规则：api.example.com的所有路径指向API后端，app.example.com的所有路径指向前端后端，未匹配请求默认走前端

我们找不到Cloud Run中给GCP生成的错误响应添加CORS头的配置选项，急需可行的解决方案。

1. 优化Cloud Run扩容配置，减少429错误产生 #

调整启动与实例数设置 #

• 开启Startup CPU boost：启用后GCP会在实例启动阶段分配额外CPU资源，大幅缩短容器初始化时间，让新实例更快进入就绪状态，减少扩容期间的请求拦截。
• 提高最小实例数：如果能预估高峰时段，提前将最小实例数从1调整到2-3个，避免从单实例突然扩容的压力。
• 提升最大实例数：当前最大实例数为5，单实例并发80的话理论可承载400并发，但扩容延迟导致拦截，可适当调高最大实例数（比如10），让GCP更快扩容到足够实例应对流量。

调整并发数 #

当前单实例并发设为80，如果NestJS API的实际处理能力达不到这个值，可适当降低并发数（比如40），让每个实例处理更少请求，降低过载概率，同时减轻扩容时的实例就绪压力。

2. 在负载均衡层注入CORS头 #

GCP在负载均衡或Cloud Run入口返回的错误响应不会自动携带CORS头，可通过负载均衡的响应头策略给所有错误响应（包括429）强制添加CORS头。

Terraform配置示例 #

1. 创建响应头策略：

resource "google_compute_response_headers_policy" "api_cors" {
  name = "api-cors-headers"

  # 给正常响应添加CORS头
  response_headers {
    headers = {
      "Access-Control-Allow-Origin" = "https://app.example.com"
      "Access-Control-Allow-Methods" = "GET, POST, PUT, DELETE, OPTIONS"
      "Access-Control-Allow-Headers" = "Content-Type, Authorization"
    }
  }

  # 给所有响应（包括GCP生成的错误）添加CORS头
  custom_response_headers {
    add = [
      "Access-Control-Allow-Origin: https://app.example.com",
      "Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS",
      "Access-Control-Allow-Headers: Content-Type, Authorization"
    ]
  }
}

2. 将策略关联到API后端服务：

resource "google_compute_backend_service" "load_balancer_backend_api" {
  name        = "load-balancer-backend-api"
  port_name   = "https"
  protocol    = "HTTPS"
  timeout_sec = 120

  backend {
    group = google_compute_region_network_endpoint_group.api_neg.id
  }

  # 绑定响应头策略
  response_headers_policy = google_compute_response_headers_policy.api_cors.id
}

配置完成后，负载均衡返回的所有响应（包括GCP生成的429）都会带上CORS头，浏览器不再拦截，Angular就能正确识别429状态码并触发重试逻辑。

3. 前端层面的兜底处理 #

如果负载均衡配置修改暂时无法落地，可在Angular前端添加全局拦截器，针对请求失败（无响应或被浏览器拦截）的情况做重试兜底：

import { Injectable } from '@angular/core';
import { HttpInterceptor, HttpRequest, HttpHandler, HttpErrorResponse } from '@angular/common/http';
import { Observable, throwError } from 'rxjs';
import { retryWhen, delay, take, tap } from 'rxjs/operators';

@Injectable()
export class RetryInterceptor implements HttpInterceptor {
  intercept(request: HttpRequest<any>, next: HttpHandler): Observable<any> {
    return next.handle(request).pipe(
      retryWhen(errors => 
        errors.pipe(
          tap((err: HttpErrorResponse) => {
            // 识别浏览器CORS拦截导致的status=0错误，视为可能的429
            if (err.status === 0) {
              console.warn('疑似扩容导致的CORS拦截，触发重试');
            }
          }),
          delay(1500), // 延迟1.5秒重试
          take(3) // 最多重试3次
        )
      ),
      catchError((err: HttpErrorResponse) => {
        // 最终处理逻辑
        return throwError(() => new Error('请求多次重试失败，请稍后再试'));
      })
    );
  }
}

记得在app.module.ts中注册这个拦截器。

4. 切换到Cloud Run第二代执行环境，启用请求排队 #

第二代执行环境支持请求排队功能，启用后GCP会在实例扩容期间缓存等待的请求，而不是直接返回429，等新实例就绪后再处理排队的请求。

Terraform配置修改： #

resource "google_cloud_run_service" "api" {
  name     = "api"
  location = "us-central1"

  template {
    spec {
      containers {
        image = "gcr.io/your-project/api-image"
      }
      # 切换到第二代执行环境
      execution_environment = "GEN_2"
      # 启用请求排队，设置队列长度（示例为1000）
      max_instance_requests = 1000
      container_concurrency = 80
    }
  }

  traffic {
    percent         = 100
    latest_revision = true
  }
}

这个功能能从根源上减少扩容时的429错误，是长期优化的首选方案。

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