Fix Kubernetes Ingress 502 Bad Gateway

Fix Kubernetes Ingress 502 Bad Gateway

You've deployed your app, created an Ingress, and hit the URL — and get:

502 Bad Gateway
nginx

A 502 from the nginx Ingress controller means nginx received the request but couldn't get a valid response from the upstream service. The Ingress itself is working — the problem is between the Ingress controller and your pods.

Step 1: Confirm the Ingress is configured correctly

kubectl describe ingress <ingress-name>

Check that:

• The host matches the hostname you're using
• The serviceName and servicePort reference the correct Service
• The Ingress has been assigned an address (in the Address field)

kubectl get ingress <ingress-name>
# NAME   CLASS   HOSTS            ADDRESS        PORTS   AGE
# api    nginx   api.example.com  203.0.113.10   80      5m

If ADDRESS is empty, the Ingress controller hasn't picked it up yet — check the controller logs.

Cause 1: Service has no endpoints (no ready pods)

This is the most common cause. The Service exists but has no pods passing their readiness probe — so nginx has nowhere to send traffic.

1# Check if the Service has endpoints
2kubectl get endpoints <service-name>
3
4# Healthy service with 2 pods behind it:
5# NAME   ENDPOINTS                     AGE
6# api    10.244.0.5:3000,10.244.1.3:3000  5m
7
8# Problem — no endpoints:
9# NAME   ENDPOINTS   AGE
10# api    <none>      5m

If endpoints are empty:

# Are the pods running?
kubectl get pods -l app=api

# Are they passing readiness probes?
kubectl describe pod <pod-name>
# Look for: Readiness probe failed

Fix: Fix the readiness probe path/port, or fix whatever is causing the pod to be unready.

Cause 2: Service selector doesn't match pod labels

The Service finds pods via label selectors. If the selector doesn't match the pod labels, endpoints stay empty.

1# Check Service selector
2kubectl get service <service-name> -o jsonpath='{.spec.selector}'
3# {"app":"api"}
4
5# Check pod labels
6kubectl get pods --show-labels | grep api
7# api-7d9f8b   Running   app=backend   ← selector is "app=api" but pod has "app=backend"

Fix: Make the Service selector and pod labels match:

1# Service
2spec:
3  selector:
4    app: api       # Must match pod labels exactly
5
6# Pod template
7metadata:
8  labels:
9    app: api       # This

Cause 3: Wrong targetPort in the Service

The Service is routing to the wrong port on the pod — the port your app actually listens on.

kubectl get service <service-name> -o yaml
# Check: spec.ports[*].targetPort

spec:
  ports:
    - port: 80
      targetPort: 3000    # Must match the port your app binds to

# Verify what port the app is actually listening on inside the pod
kubectl exec <pod-name> -- ss -tlnp
# or
kubectl exec <pod-name> -- netstat -tlnp

Fix: Set targetPort to the port the application process actually binds to.

Cause 4: Wrong servicePort in the Ingress

The Ingress backend references a Service port number or name. If it doesn't match a port declared in the Service, requests fail.

1# Ingress
2backend:
3  service:
4    name: api
5    port:
6      number: 80    # Must match a port in the Service spec
7
8# Service
9spec:
10  ports:
11    - port: 80       # ← this must exist
12      targetPort: 3000

Cause 5: App is crashing or taking too long to respond

If pods are running and the Service has endpoints, but you're still getting 502, the app itself may be crashing mid-request or timing out.

# Watch pod logs in real time while making a request
kubectl logs -f <pod-name>

# Check Ingress controller logs for the upstream error
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx --tail=50

Look for lines like:

upstream prematurely closed connection while reading response header
connect() failed (111: Connection refused)

Fix: This is an application issue — the app is binding to the wrong address (must bind to 0.0.0.0, not 127.0.0.1), crashing under load, or taking longer than the proxy timeout allows.

For timeout issues, increase the proxy timeout via annotation:

metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "120"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "120"

Diagnostic flow

1# 1. Does the Ingress have an address?
2kubectl get ingress <name>
3
4# 2. Does the Service exist and have endpoints?
5kubectl get endpoints <service-name>
6
7# 3. Are pods running and ready?
8kubectl get pods -l <selector>
9kubectl describe pod <pod-name>    # Look for readiness probe failures
10
11# 4. Can you reach the service directly (bypassing Ingress)?
12kubectl port-forward service/<service-name> 8080:80
13curl http://localhost:8080/health
14
15# 5. Check Ingress controller logs
16kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx --tail=100

If step 4 works (direct Service access) but the Ingress returns 502, the issue is in the Ingress configuration itself (wrong port, missing annotation, TLS mismatch). If step 4 also fails, the problem is at the Service or pod level.

See also

• Fix: Kubernetes Pending Pods — pods never scheduled
• Fix: Kubernetes CrashLoopBackOff — pods crashing after startup
• Kubernetes Networking & Ingress — how Services and Ingress work together

Frequently Asked Questions

What does a 502 from the ingress actually mean?

The controller accepted your request and could not get a valid response from the backend. That narrows it to the Service, the endpoints behind it, or the application itself — the ingress is working, which is useful information. Check endpoints before touching ingress configuration.

Why does my Service have no endpoints?

Its selector matches no running pod's labels, or matching pods are not ready. Compare the selector against pod labels rather than the Deployment's, since the pod template produces them. A pod failing readiness is deliberately excluded, which is a 502 with a healthy-looking deployment.

Could the port be wrong even though everything looks right?

Yes, and it is common. The Service targetPort must match the port the container actually listens on, not the Service's own port. An application bound to localhost rather than all interfaces produces the same symptom — reachable inside the container, unreachable from the pod network.

When is a timeout the cause rather than a connection failure?

When the backend is up and slow. The ingress has its own read and send timeouts, and a request exceeding them returns 502 or 504 even though the application would eventually have answered. If the 502s correlate with slow endpoints rather than restarts, look at timeouts.

Official References

• Ingress — path types, backends and the ingress controller contract
• Debug Pods — reading pod status, events and container states
• kubectl reference — command syntax, output formats and selectors
• nginx documentation — directives for proxying, load balancing and TLS