Ingress and Load Balancer Errors — 502, 503, 504, 404, 413 and TLS

The errors users see at the edge of a Kubernetes cluster: what each status code proves about where the request stopped, the first command for each, and how it looks on EKS, AKS, GKE and Gateway API.

Overview

Ingress and load balancer errors are the ones your users see. They happen on the way in, often before the request reaches your code, so the pods can look perfectly healthy while every request fails. The job at this layer is to find where the request stopped: at the cloud load balancer, at the Ingress controller (or Gateway), at the Service and its EndpointSlices, or at the pod itself.

The one idea to keep: the status code tells you how far the request got. With an NGINX-based controller, a 404 means no rule matched, a 503 means a rule matched but there was no ready backend, a 502 means the proxy reached a backend and the conversation broke, and a 504 means a backend accepted the request and did not answer in time. A TLS error means the connection failed before HTTP started at all. Read the code first and you already know which object to open. Be careful with one detail: that mapping belongs to the proxy, not to HTTP. Envoy-based gateways return 503 for a failed upstream connection, and Azure Application Gateway returns 502 for an empty backend pool, so always ask which proxy produced the page.

Work from the outside in: start with the proxy's own log line for the failing request, then the Service's EndpointSlices, then the pod. Starting at the pod wastes time, because a healthy pod says nothing about whether the proxy could reach it. Two facts from 2025-2026 shape this page: the community ingress-nginx controller was retired in March 2026 (no more releases or security fixes; existing installs keep running), and the Kubernetes project now recommends Gateway API over the frozen Ingress API. Every section therefore also says how the same failure shows up on an HTTPRoute.

Symptom to first command

503 Service Unavailable — The Service has no ready endpoints — kubectl get endpointslices -n prod -l kubernetes.io/service-name=orders
504 Gateway Timeout — The backend answered too slowly for the shortest timeout in the chain — kubectl logs -n ingress-nginx deploy/ingress-nginx-controller --tail=200
404 from nginx, nothing in the app log — No host and path rule matched — kubectl describe ingress orders -n prod
Certificate expired or wrong name — Renewal failing, missing Secret, or name not in the SAN — openssl s_client -connect api.example.com:443 -servername api.example.com
413 Request Entity Too Large — Body bigger than the proxy limit (1 MB default in ingress-nginx) — kubectl get ingress orders -n prod -o yaml and look for proxy-body-size
502 Bad Gateway — Connection refused, reset, or wrong protocol to the pod — kubectl logs -n ingress-nginx deploy/ingress-nginx-controller --tail=200
LoadBalancer EXTERNAL-IP stays pending — The cloud controller cannot or will not create the load balancer — kubectl events -n prod --for service/orders-lb
502 or 503 bursts during every deploy — Pods stop listening before proxies stop sending — kubectl get deploy orders -n prod -o yaml and look for preStop
Ingress has no ADDRESS — No controller claims it (class missing or wrong) — kubectl get ingress -A -o wide and kubectl get ingressclass
HTTPRoute gives 404 or 500 — Route not Accepted, or a backendRef that does not resolve — kubectl describe httproute orders -n prod

What you will be able to do

Name the hop that failed from the status code, the proxy that produced it, and one log line.
Run the first command for each failure against the orders Service in prod and read the result.
Explain the rolling-update 502 race and fix it with a preStop hook, a grace period and a surge-first rollout.
Say how the same failure appears on EKS, AKS and GKE, and on a Gateway API HTTPRoute.
Add the guardrail that stops each failure from coming back.

Key concepts

Status code as location: With an NGINX proxy, 404 means no rule matched, 503 no ready backend, 502 the backend connection broke, 504 the backend was too slow. Other proxies map some cases differently, so always note which proxy answered.
EndpointSlice: The object that lists a Service's pod addresses with ready, serving and terminating conditions. Proxies route from it. The older Endpoints API is deprecated since Kubernetes 1.33.
Default backend: Where an Ingress controller sends requests that match no host and path rule. It answers 404, and the app never sees the request.
IngressClass: Names the controller that should implement an Ingress. With no ingressClassName and no default class, no controller acts, and nothing reports an error.
Shortest timer wins: Every hop (cloud load balancer, Ingress, app server, client) has its own timeout, and a 504 comes from whichever is shortest.
preStop hook: Runs before SIGTERM when a pod is deleted. A short sleep here keeps the pod serving while proxies learn it is going away.
Keep-alive race: If the app closes idle connections sooner than the proxy does, the proxy can reuse a socket the app just closed and return a 502.
HTTPRoute conditions: Gateway API status per parent: Accepted says the Gateway took the route, ResolvedRefs says every backend reference works. The reasons name the exact problem.
ingress-nginx retirement: The community controller was retired in March 2026: no more releases or security fixes. Existing installs keep running. The project recommends Gateway API.

When to use it

Users report 5xx or 404 errors while the pods look healthy.
A deploy produces a short burst of 502 or 503 errors every time.
A certificate expired, or the browser shows the Kubernetes Ingress Controller Fake Certificate.
Uploads fail with 413, or long-lived sessions fail with 400 on large headers.
A LoadBalancer Service or an Ingress never gets an external address.
You are moving from ingress-nginx to Gateway API and need to read HTTPRoute status.

Interview questions

After a deploy, users see intermittent 502s for about 20 seconds, then everything is fine. Walk me through it.
An Ingress returns 503 for one service while the pods show Running. How do you find the cause in under five minutes?
A report endpoint returns 504 after exactly 30 seconds on GKE, even though you set proxy-read-timeout to 180 on the Ingress. Why?
A new NetworkPolicy went out and now some requests through the Ingress hang and fail with 504, while pods in the same namespace can call the service fine. What happened?
How does diagnosing a 502 differ between ingress-nginx on EKS, AGIC on AKS and GKE Ingress?
A browser shows the Kubernetes Ingress Controller Fake Certificate for your production host. What do you check, in order?
Your company still runs ingress-nginx. What is your plan, and what changes in how you debug?