Ingress 502: The ingress reached a backend and got an invalid response

A 502 from an ingress means the controller connected to a backend pod and the response was unusable — a connection refused mid-request, a protocol mismatch, or the backend closing early.

Applies to: All Kubernetes versions with an ingress controller

What it means

A 502 is generated by the ingress controller, not by the application, and it means the controller had somewhere to send the request but could not get a valid response back. This separates it from a 503, where the controller had no backend to try at all. The common shapes are a backend that accepted the connection and then closed it, a protocol mismatch where the controller speaks HTTP to a port serving HTTPS or gRPC, and a backend that crashed while handling the request. Because the controller is the one reporting, its own logs are far more informative than the application's, and they name the upstream address it tried.

Most common causes

• The backend pod crashed or restarted while handling the request.
• A protocol mismatch — the controller sending plain HTTP to a TLS port, or HTTP/1.1 to a gRPC service without the right backend protocol annotation.
• The Service's targetPort points at a port that is open but serves something else.
• The backend closed the connection before sending a complete response, for example on its own internal error.
• A response header larger than the controller's buffer.
• A backend that requires the client to speak HTTP/2 or a specific ALPN protocol.

How to diagnose it

1. Read the ingress controller's logs — they name the upstream address and the failure: kubectl logs -n INGRESS_NS -l app.kubernetes.io/name=ingress-nginx or the equivalent for your controller.
2. Bypass the ingress and call the Service directly from inside the cluster. If that works, the problem is between the controller and the Service.
3. Call the pod IP directly to separate the Service from the pod.
4. Check whether the backend expects TLS: kubectl exec POD -- ss -ltn and the application's configuration.
5. Check backend restarts at the time of the 502s: kubectl get pods -w during a reproduction.

How to fix it

1. Set the backend protocol correctly on the Ingress — most controllers have an annotation for HTTPS, gRPC, or HTTP/2 upstreams.
2. Correct the Service's targetPort to the port that actually serves the expected protocol.
3. Fix the backend crash, using the application's logs and its exit code.
4. Raise the controller's proxy buffer size if the failure is a large response header.
5. Ensure the backend keeps connections open long enough for the controller's keepalive settings, or shorten the controller's.

Notes

502 and 503 are worth separating carefully. A 502 proves the ingress had a backend to try, which means Service endpoints exist and the problem is in the conversation with the pod. A 503 means it had nothing to try at all.

Related

• Ingress 503 — The ingress has no healthy backend
• Ingress 504 — The backend did not respond in time

Sources

• Kubernetes documentation — Ingress
• Kubernetes documentation — Ingress Controllers
• Kubernetes documentation — Debug Services