GCP外部负载均衡对接gRPC后端故障排查求助

结合你的测试报错和流量路径，以下是几个关键的配置遗漏可能性：

1. 健康检查类型不匹配导致后端被标记为不健康 #

你配置了HTTP健康检查，但gRPC服务默认不处理普通HTTP GET请求。负载均衡器会因为健康检查失败，将后端实例标记为不可用，进而丢弃流量（对应grpcurl报错里的drop overload属于LB的流量丢弃逻辑）。

• 解决：将LB的健康检查改为gRPC健康检查，指定gRPC健康检查的默认路径/grpc.health.v1.Health/Check；或者在你的gRPC服务中额外实现一个HTTP接口，匹配LB健康检查的请求路径和方法。

2. 负载均衡器到后端的HTTP/2转发配置缺失 #

gRPC依赖HTTP/2协议，若LB仅在前端支持HTTP/2，但将流量以HTTP/1.1转发到后端的5555端口，会导致gRPC服务无法解析请求，出现415错误。

• 解决：确认LB的后端服务配置中，明确指定与后端通信的协议为HTTP/2；如果后端是明文HTTP/2（h2c），需确保LB支持h2c转发，而非强制用HTTPS连接后端。

3. 后端伪TLS的适配配置 #

你的后端使用伪TLS（自签证书或明文HTTP/2），需对应调整LB的后端连接配置：

• 如果后端是自签TLS证书：LB需要配置忽略后端证书验证，否则会因证书不被信任而无法建立连接。
• 如果后端是明文HTTP/2（h2c）：LB不能以HTTPS协议连接后端5555端口，需改为HTTP协议并启用HTTP/2转发。

4. 请求头转发与路由规则问题 #

gRPC要求请求必须携带Content-Type: application/grpc头，若LB在转发时过滤或修改了该头，会导致后端服务返回415错误（对应curl测试的invalid gRPC request content-type ""）。

• 解决：检查LB的请求头转发规则，确保保留所有gRPC相关的请求头（包括Content-Type、grpc-timeout等）；同时确认路由规则覆盖所有gRPC请求路径（比如/*，因为gRPC请求路径通常为/package.Service/Method格式）。

5. gRPC服务反射未启用（辅助排查点） #

虽然当前报错主要是流量可达性问题，但如果后续解决了连接问题仍无法用grpcurl list，需确认你的gRPC服务是否启用了服务器反射功能，grpcurl依赖该功能列出服务。

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