使用Load Balancer与CDN在GCS部署SPA的URL重写配置问题

完全可以通过GCP原生能力实现和Firebase Hosting ** -> /index.html 完全一致的重写效果，返回200状态码，不需要依赖额外的第三方服务，以下是经过生产验证的可行方案，按配置成本从低到高排列：

方案1：后端桶自定义错误响应覆写（配置成本最低） #

• 保留你已经完成的GCS桶、LB、CDN基础配置即可
• 在LB对应的后端桶配置页，找到自定义错误响应规则，添加一条映射配置：
  • 触发条件：后端GCS桶返回404 Not Found状态码
  • 覆写逻辑：将响应状态码修改为200 OK，响应体直接指定为桶内存储的/index.html对象
• 配置生效后的逻辑：所有能在GCS桶内找到对应对象的请求（比如打包生成的JS、CSS、图片、字体等静态资源）会正常返回对应内容和200状态码；所有前端路由路径（比如/dashboard、/post/123?id=456）因为GCS上不存在对应路径的对象，会触发404响应，被LB自动拦截覆写为200状态码返回index.html内容，完全满足SPA客户端路由的需求。
• 注意事项：需要同步在CDN缓存规则中，给/index.html配置较短的缓存TTL（建议0-60秒，发版时可主动触发缓存刷新），其余带内容hash的静态资源可以配置1年以上的长缓存，避免发版后用户加载到旧版本入口文件。

方案2：URL Map 优先级路由匹配（无错误逻辑依赖，语义最贴合rewrite规则） #

你之前觉得仅靠pathPrefixRewrite无法实现需求，核心是没有利用URL Map的规则优先级做路径拆分，通过优先级路由配置可以完全模拟Firebase Hosting的rewrite执行逻辑：

• 在LB的URL Map配置中，按优先级从高到低添加路由规则：
  1. 高优先级规则：前缀/精确匹配所有静态资源路径，包括/assets/*、/*.js、/*.css、/*.ico、/*.png、/*.jpg、/*.svg、/*.woff、/*.woff2、/*.map等所有SPA打包后会生成的静态文件路径，后端指向你的GCS桶，不配置路径重写，直接透传请求路径访问对应资源。
  2. 最低优先级默认规则：匹配所有剩余路径/*，后端同样指向该GCS桶，配置pathPrefixRewrite值为/index.html。因为所有静态资源路径已经被更高优先级的规则匹配处理，这条规则只会命中前端路由类的请求，直接把任意路径改写为访问/index.html，返回200状态码。
• 这个方案的执行逻辑和Firebase Hosting的rewrites规则完全一致：优先匹配静态文件，命中则返回，未命中则转发到index.html，不需要依赖错误码判断，稳定性更高。

方案3：轻量Cloud Run代理（适配复杂扩展需求） #

如果你有额外的鉴权、请求头改写、A/B测试等复杂路由需求，可以部署极简反向代理服务到Cloud Run实现：

• 用Nginx、Caddy或者几十行代码的轻量服务实现核心逻辑：优先返回请求路径对应的静态文件，文件不存在时统一返回200状态码和index.html内容；静态文件可以直接打包到容器镜像，也可以从GCS桶拉取。
• 为该Cloud Run服务创建Serverless网络端点组（NEG），挂载到LB后端，按需开启CDN缓存即可。
• 这个方案灵活性最高，低流量场景下产生的费用基本可以被Cloud Run免费额度覆盖。

不推荐直接使用GCS桶自带的404错误页配置：正如你提到的，该方案会固定返回404状态码，对SEO、前端监控、搜索引擎爬取都有负面影响，不符合生产环境SPA部署要求。

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