How to fix upstream connect error or disconnect/reset before headers. reset reason: overflow in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated May 28, 2026· 887 views

Fix Envoy/Istio 503 "upstream connect error". Covers reset reasons: overflow, connection termination, timeout. Check service, endpoints, mTLS.

Quick fix

Fixes upstream connect error or disconnect/reset before headers. reset reason: overflow

# Check listening ports in the pod
kubectl exec -it <pod-name> -- netstat -tlnp
# or
kubectl exec -it <pod-name> -- ss -tlnp
  1. Verify application listens on 0.0.0.0
  2. Verify service selector matches pod labels
  3. Check pod health and readiness probes
  4. Verify port configuration
kubernetes — error
# Check listening ports in the pod
kubectl exec -it <pod-name> -- netstat -tlnp
# or
kubectl exec -it <pod-name> -- ss -tlnp
upstream connect error or disconnect/reset before headers. reset reason: overflow

What this error means

The "upstream connect error or disconnect/reset before headers" error indicates that the proxy (Envoy, NGINX, or Istio sidecar) successfully resolved the service but failed to establish a connection to the upstream pod. The connection was either refused, reset, or timed out before receiving any response headers. This is one of the most common networking issues in Kubernetes environments using service meshes or ingress controllers. It means traffic reached the proxy layer but couldn't complete the connection to the actual application pod. Common causes include applications binding to localhost instead of all interfaces, pods crashing or being unhealthy, port mismatches between service and container, or expired mTLS certificates in service mesh configurations.

Typical symptoms

  • HTTP 502 Bad Gateway or 503 Service Unavailable responses
  • Error logs show "upstream connect error" or "connection reset"
  • Intermittent failures under load
  • Service works via port-forward but fails through ingress
  • Connection refused (errno 111 ECONNREFUSED) in proxy logs

Common causes

  1. Application listening on 127.0.0.1 instead of 0.0.0.0
  2. Service selector doesn't match pod labels (empty endpoints)
  3. Pod crashes or becomes unhealthy after receiving traffic
  4. Port mismatch between service targetPort and container port
  5. mTLS certificate expiration in service mesh

How to fix "upstream connect error or disconnect/reset before headers. reset reason: overflow"

1Verify application listens on 0.0.0.0

Check what address the application is binding to:

bash
# Check listening ports in the pod
kubectl exec -it <pod-name> -- netstat -tlnp
# or
kubectl exec -it <pod-name> -- ss -tlnp

Look for 0.0.0.0:8080 (correct), not 127.0.0.1:8080 (problem).

Fix in application configuration:

dockerfile
# For Node.js
ENV HOST=0.0.0.0

# In application code
server.listen(8080, '0.0.0.0')
2Verify service selector matches pod labels

Check that service endpoints are populated:

bash
# Get service selector
kubectl get service my-service -o yaml | grep -A3 selector

# Check pod labels
kubectl get pods --show-labels

# Verify endpoints exist
kubectl get endpoints my-service
kubectl get endpointslices -l kubernetes.io/service-name=my-service

If endpoints are empty, update labels to match:

yaml
# Service selector
spec:
  selector:
    app: my-app  # Must match pod labels

# Pod labels
metadata:
  labels:
    app: my-app  # Must match service selector
3Check pod health and readiness probes

Verify pods are healthy and passing probes:

bash
# Check pod status
kubectl get pods -o wide

# Look for probe failures
kubectl describe pod <pod-name> | grep -A5 "Readiness"

# Check events for crash reasons
kubectl get events --field-selector involvedObject.name=<pod-name>

Configure proper readiness probe:

yaml
readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 3
4Verify port configuration

Ensure ports align between container, service, and ingress:

bash
# Check container port
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].ports}'

# Check service ports
kubectl get service my-service -o yaml | grep -A5 ports

# Test connectivity directly
kubectl port-forward <pod-name> 8080:8080
curl http://localhost:8080/health

Correct configuration:

yaml
# Container
ports:
- containerPort: 8080  # App listens here

# Service
ports:
- port: 80             # Service exposes this
  targetPort: 8080     # Routes to container port
5Debug proxy and ingress logs

Check proxy logs for connection errors:

bash
# NGINX Ingress logs
kubectl logs -n ingress-nginx deployment/ingress-nginx-controller | grep "upstream"

# Istio sidecar logs
kubectl logs <pod-name> -c istio-proxy | grep "upstream"

# Envoy admin interface (if available)
kubectl port-forward <pod-name> 19000:19000
# Visit http://localhost:19000/config_dump

Look for:
- "connection refused" - port not listening
- "connection reset" - app crashed
- "no healthy upstream" - all pods unhealthy

6Configure timeouts and retries

For Istio/Envoy, configure retry and timeout policies:

yaml
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-service
spec:
  hosts:
  - my-service
  http:
  - timeout: 30s
    retries:
      attempts: 3
      perTryTimeout: 10s
      retryOn: "5xx,reset,connect-failure"
    route:
    - destination:
        host: my-service
        port:
          number: 8080

For NGINX Ingress, use annotations:

yaml
annotations:
  nginx.ingress.kubernetes.io/proxy-connect-timeout: "30"
  nginx.ingress.kubernetes.io/proxy-read-timeout: "30"

Advanced notes

Connection Pool Configuration (Istio/Envoy):

yaml
trafficPolicy:
  connectionPool:
    http:
      http1MaxPendingRequests: 100
      http2MaxRequests: 100
    tcp:
      maxConnections: 100

Outlier Detection (passive health checks):

yaml
outlierDetection:
  consecutive5xxErrors: 5
  interval: 30s
  baseEjectionTime: 30s

Common Patterns:
- Pod-to-pod works but ingress fails → Check ingress backend protocol
- Works initially then fails → Check resource limits, OOM kills
- Intermittent under load → Connection pool exhaustion, scale pods

Backend Protocol: If backend serves HTTPS:

yaml
annotations:
  nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

Frequently asked questions

What does "upstream connect error or disconnect/reset before headers. reset reaso" mean?
The "upstream connect error or disconnect/reset before headers" error indicates that the proxy (Envoy, NGINX, or Istio sidecar) successfully resolved the service but failed to establish a connection to the upstream pod. The connection was either refused, reset, or timed out before receiving any response headers. This is one of the most common networking issues in Kubernetes environments using service meshes or ingress controllers.
How do I fix "upstream connect error or disconnect/reset before headers. reset reaso"?
Fix Envoy/Istio 503 "upstream connect error". Covers reset reasons: overflow, connection termination, timeout. Check service, endpoints, mTLS.
What causes "upstream connect error or disconnect/reset before headers. reset reaso"?
Application listening on 127.0.0.1 instead of 0.0.0.0 Service selector doesn't match pod labels (empty endpoints) Pod crashes or becomes unhealthy after receiving traffic
Is the "upstream connect error or disconnect/reset before headers. reset reaso" 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