This is the trap of a misconfigured load balancer with gRPC. HTTP/1.1 health checks pass. Ports are open. Yet the client hits UNAVAILABLE, UNIMPLEMENTED, or abrupt stream resets. Load balancers that speak only HTTP/1.1 break gRPC’s HTTP/2 streams. They might downgrade the protocol, strip headers, or close idle connections too early.
A gRPC load balancer error often comes from one of three causes:
- Protocol mismatch – gRPC requires HTTP/2 end-to-end. If the balancer downgrades to HTTP/1.1, requests fail.
- Timeout and keepalive handling – Default TCP or connection idle timers can cut active streams. Proper
grpc-keepalivesettings on both sides are essential. - Header forwarding – Missing or altered pseudo-headers like
:authorityor:pathcan cause gRPC servers to reject requests silently.
Debugging starts with confirming protocol support. Inspect negotiated protocols with curl --http2 -v or use Wireshark to verify HTTP/2 frames pass through the balancer. Disable connection coalescing if SNI or client certificate mismatch occurs. For cloud load balancers, enable HTTP/2 explicitly and set idle timeouts above gRPC's default keepalive pings.