GCP负载均衡器URL地图配置后仅默认后端响应请求问题排查

先明确GCP路由的判定逻辑 #

GCP的URL地图不存在「配置语法合规就一定按规则转发」的保障，路由优先级严格按最长匹配优先、健康状态兜底的规则执行，只要自定义规则存在细微偏差，或者后端状态异常，所有流量都会被静默导去默认后端。

逐项排查修正 #

• 校验路径规则的配置格式
  • 给Auth服务配置路由时，不要只写不带通配的/auth就结束，还要确认匹配类型没有被选成「精确匹配」。正确的配置是填写/auth/*，匹配类型选择「前缀匹配」。如果只配置了精确匹配的/auth，只有路径完全等于/auth的请求能被正确转发，像/auth/test这类带子路径的请求，会直接命中默认后端的宽泛规则。
  • 不要给默认后端额外添加/*的路径规则，这个带通配的规则优先级比不带通配的短路径规则更高，会直接覆盖自定义规则的匹配效果。默认后端无需单独配置路径匹配规则，直接绑定到URL地图的默认后端字段即可。
• 排查规则层级冲突
  • 确认配置的路径规则挂载在全局「所有主机」分类下。如果路径规则绑定在特定Host的专属配置中，而实际请求的Host头和绑定的Host不匹配，所有自定义规则都会被跳过，全部流量走默认后端。
  • 检查历史配置是否存在主机级覆盖：如果之前为请求对应的Host配置了独立的默认后端，后续在全局新增的路径规则不会生效，需要进入对应Host的规则详情页补充路径映射。
• 核验后端服务健康状态
  • 进入Auth服务对应的后端详情页，确认健康检查状态为「健康」。如果健康检查连续失败，GCP会自动将该后端从可路由节点列表中移除，所有原本要匹配到该后端的请求会被静默转发到默认后端，整个过程前端不会弹出明显告警，极易被忽略。
  • 核对健康检查配置参数：端口、请求路径需要和NestJS容器实际暴露的端口、健康检查接口完全匹配，避免出现健康检查请求打到非业务端口，导致后端永远被判定为不健康的情况。
• 校验路径重写逻辑
  • 如果开启了路径重写规则，需要确认重写后的路径和NestJS应用本身的路由前缀匹配。比如Auth服务本身的路由是/auth/test，不要在转发时把/auth/*的请求重写为/*，否则哪怕流量正确路由到Auth服务，应用也会因为路径不匹配返回404，造成路由失效的观感。

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