How to fix 502 Bad Gateway in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 249 views

The Ingress controller cannot reach healthy backend pods because they are failing health checks, restarting, or not listening on the expected port. A 502 indicates the gateway received an invalid response from the upstream service, typically due to readiness probe failures, port mismatches, or pods crashing. Fix by ensuring backend pods are healthy and ports match the service configuration.

Quick fix

Fixes 502 Bad Gateway

kubectl get pods -n <namespace> -o wide
kubectl describe pod <pod-name> -n <namespace> | grep -A10 "Conditions"
  1. Check backend pod readiness status
  2. Verify backend pod ports match Ingress service
  3. Check application logs for errors
  4. Increase readiness probe timeout
kubernetes — error
kubectl get pods -n <namespace> -o wide
kubectl describe pod <pod-name> -n <namespace> | grep -A10 "Conditions"
502 Bad Gateway

What this error means

A 502 Bad Gateway error from an Ingress controller (nginx, traefik, etc.) means the Ingress received traffic but couldn't reach a healthy backend pod. The backend service exists but all pods are either not ready (readiness probe failing), crashing, or not listening on the configured port. This differs from 503 (no endpoints) in that endpoints exist but are unhealthy.

Typical symptoms

  • 502 Bad Gateway when accessing ingress domain
  • Works when accessing service directly or via port-forward
  • Readiness probe failures in pod events
  • Backend pods restarting constantly
  • Response size exceeds Ingress buffer limits
  • Intermittent 502 errors under load

Common causes

  1. All backend pods failing readiness probes
  2. Backend pod port doesn't match service targetPort
  3. Application crash or hang, slow to respond
  4. Insufficient resources (CPU/memory pressure)
  5. Readiness probe too strict or timeout too short
  6. Large response bodies exceeding proxy buffer size
  7. Pod timeout before Ingress proxy timeout

How to fix "502 Bad Gateway"

1Check backend pod readiness status

Examine pod readiness:

bash
kubectl get pods -n <namespace> -o wide
kubectl describe pod <pod-name> -n <namespace> | grep -A10 "Conditions"

Look for "Ready" condition. If False, readiness probe is failing. Check:

bash
kubectl describe pod <pod-name> -n <namespace> | grep -A5 "Readiness probe"
2Verify backend pod ports match Ingress service

Check the full port chain:

bash
# Ingress backend service
kubectl get ingress <ingress-name> -n <namespace> -o yaml | grep -A10 "backend:"

# Service port configuration
kubectl get service <service-name> -n <namespace> -o yaml | grep -A5 "ports:"

# Pod listening port
kubectl exec <pod-name> -n <namespace> -- netstat -tlnp | grep LISTEN

All three must align: ingress → service targetPort → pod containerPort.

3Check application logs for errors

Review pod logs:

bash
kubectl logs <pod-name> -n <namespace> --tail=100
kubectl logs <pod-name> -n <namespace> -p  # Previous pod (if crashed)

Look for startup errors, port binding failures, or exceptions.

4Increase readiness probe timeout

If application starts slowly, increase timeouts:

yaml
readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10  # Increased from 0
  timeoutSeconds: 3        # Increased from 1
  periodSeconds: 5
  failureThreshold: 2

Redeploy and monitor.

5Allocate more resources to pods

Resource starvation causes timeouts and hangs:

bash
kubectl top pod <pod-name> -n <namespace>
kubectl describe node <node-name> | grep -A10 "Allocated resources"

Increase resource requests/limits:

yaml
resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    cpu: 1000m
    memory: 1Gi
6Test health endpoint directly

Port-forward and test the readiness endpoint:

bash
kubectl port-forward pod/<pod-name> 8080:8080 -n <namespace> &
curl -v http://localhost:8080/health

If endpoint returns error or hangs, fix the application health check logic.

7Check Ingress controller buffer settings

Large responses may exceed proxy buffer size:

bash
kubectl describe ingress <ingress-name> -n <namespace>

For nginx-ingress, add annotation:

yaml
annotations:
  nginx.ingress.kubernetes.io/proxy-body-size: "50m"
  nginx.ingress.kubernetes.io/proxy-connect-timeout: "10"
  nginx.ingress.kubernetes.io/proxy-send-timeout: "30"
  nginx.ingress.kubernetes.io/proxy-read-timeout: "30"

Advanced notes

Unlike 503, a 502 means the Ingress controller found endpoints but they're unhealthy. Check Ingress controller logs: kubectl logs -n ingress-nginx deployment/nginx-ingress-controller. Use tcpdump on pod to verify traffic arrives: sudo tcpdump -i any port 8080. For connection pools, ensure backend isn't rejecting connections due to queue limits. Graceful shutdown is critical; ensure pods have preStop hooks to drain connections before termination.

Frequently asked questions

What does "502 Bad Gateway" mean?
) means the Ingress received traffic but couldn't reach a healthy backend pod. The backend service exists but all pods are either not ready (readiness probe failing), crashing, or not listening on the configured port. This differs from 503 (no endpoints) in that endpoints exist but are unhealthy.
How do I fix "502 Bad Gateway"?
The Ingress controller cannot reach healthy backend pods because they are failing health checks, restarting, or not listening on the expected port. A 502 indicates the gateway received an invalid response from the upstream service, typically due to readiness probe failures, port mismatches, or pods crashing. Fix by ensuring backend pods are healthy and ports match the service configuration.
What causes "502 Bad Gateway"?
All backend pods failing readiness probes Backend pod port doesn't match service targetPort Application crash or hang, slow to respond
Is the "502 Bad Gateway" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading