GCP负载均衡反向代理规则失效问题求助

核心原因：prefixMatch 格式错误 #

GCP URL映射的prefixMatch字段本身就是前缀匹配规则，不需要添加*。你配置的/pages/*和/blog/*会被系统识别为精确匹配包含星号的路径（例如只有请求https://mysite.com/pages/*这类字面路径才会触发规则），而实际业务中的/pages/xxx、/blog/xxx路径完全无法匹配，导致这条优先级2的规则从未生效，请求直接落入默认服务返回404。

修正后的完整配置 #

defaultService: projects/my-gcp-project-1/global/backendServices/my-default-service
name: redirect-rules
routeRules:
- urlRedirect:
    hostRedirect: subdomain.mysite.com
    redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
  matchRules:
  - prefixMatch: /rad-page-1
  - prefixMatch: /rad-page-2
  priority: 1
- matchRules:
  - prefixMatch: /pages
  - prefixMatch: /blog
  priority: 2
  routeAction:
    weightedBackendServices:
    - backendService: projects/my-gcp-project-1/global/backendServices/proxy-backend-service
      weight: 100
    urlRewrite:
      hostRewrite: mysite.webflow.io  # 必须指定WebFlow的真实域名，而非自身站点域名

关键调整说明 #

1. 修正hostRewrite配置：你原本设置的hostRewrite: www.mysite.com会导致转发请求时，Host头被替换为自身站点域名，但你的后端服务关联的是指向mysite.webflow.io的外部NEG，第三方WebFlow服务需要正确的Host头才能返回有效内容，因此必须将hostRewrite改为mysite.webflow.io。
2. 关于preserveHost的使用：仅当WebFlow支持以你的自定义域名（mysite.com/www.mysite.com）提供服务时，才需要在routeAction下添加preserveHost: true来保留客户端请求的Host头。针对当前代理到第三方服务的场景，不需要启用该配置。

后续验证步骤 #

• 检查外部NEG配置：确认NEG已正确指向mysite.webflow.io，端口设置符合WebFlow服务要求（通常为80或443）。
• 确认后端服务健康状态：在GCP控制台的「负载均衡>后端服务」页面，查看proxy-backend-service的健康检查是否通过。若健康检查失败，LB不会将流量转发至该后端。
• 验证URL映射关联状态：确保修改后的URL映射已绑定到目标HTTP(S)代理，且代理已更新至负载均衡器的转发规则。

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