How to fix getsockopt: connection refused in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 245 views

Health check probes fail because they cannot connect to the container on the specified port. The container may not be listening on that port, initialDelaySeconds is too low, or the container isn't starting properly. Fix by increasing initialDelaySeconds, verifying the port is correct, or checking why the application failed to start.

Quick fix

Fixes getsockopt: connection refused

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 60  # Increased
  periodSeconds: 10
  failureThreshold: 3
  1. Increase initialDelaySeconds
  2. Verify the port is correct
  3. Check if container is actually listening
  4. Ensure application listens on 0.0.0.0, not 127.0.0.1
kubernetes — error
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 60 # Increased
periodSeconds: 10
failureThreshold: 3
getsockopt: connection refused

What this error means

When Kubernetes runs a health probe (liveness, readiness, or startup), it attempts to connect to a container on a specified port and path. If the connection fails with "connection refused," it means either: (1) the container isn't listening on that port, (2) the container hasn't started yet, or (3) the port is blocked. The probe runs at regular intervals; repeated failures trigger container restarts (liveness) or remove the pod from service (readiness).

Typical symptoms

  • Pod continuously restarts with liveness probe failures
  • Pod remains NotReady with readiness probe failures
  • Pod status shows CrashLoopBackOff or ImagePullBackOff
  • Error message shows "connection refused" or "getsockopt"
  • Application works locally but fails in Kubernetes
  • Some replicas fail while others succeed

Common causes

  1. initialDelaySeconds too low; probe runs before application starts listening
  2. Container listening on wrong port (e.g., 8080 but probe checks port 80)
  3. Application crashed before probe could connect
  4. Container not bound to 0.0.0.0:port; only listening on 127.0.0.1
  5. Network policies or firewalls blocking access to container port
  6. Insufficient resources preventing application startup
  7. Wrong probe path or missing health endpoint

How to fix "getsockopt: connection refused"

1Increase initialDelaySeconds

Default (0) is usually too low. Allow time for startup:

yaml
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 60  # Increased
  periodSeconds: 10
  failureThreshold: 3
2Verify the port is correct

Check what port the application listens on:

bash
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> | grep -i "listen\|port"

Ensure the probe port matches the application's actual listening port.

3Check if container is actually listening

Exec into the container and verify:

bash
kubectl exec -it <pod-name> -n <namespace> -- netstat -tulpn | grep LISTEN
# Or
kubectl exec -it <pod-name> -n <namespace> -- ss -tulpn

Look for the port the probe is checking.

4Ensure application listens on 0.0.0.0, not 127.0.0.1

Containers listening only on 127.0.0.1 reject external probe connections. Configure application to listen on 0.0.0.0:port or use localhost if probe connects locally.

5Check application startup logs

View full logs to find startup errors:

bash
kubectl logs <pod-name> -n <namespace> --tail=100
kubectl logs <pod-name> -n <namespace> --previous  # Previous restart

Advanced notes

Use startup probes to give slow-starting applications extended startup time. Ensure probe path returns 2xx/3xx status. Verify network policies don't block probe traffic. For custom ports, ensure they're exposed in the container spec. TCP probes are simpler if HTTP endpoint unavailable—they just verify port is listening.

Frequently asked questions

What does "getsockopt: connection refused" mean?
When Kubernetes runs a health probe (liveness, readiness, or startup), it attempts to connect to a container on a specified port and path. If the connection fails with "connection refused," it means either: (1) the container isn't listening on that port, (2) the container hasn't started yet, or (3) the port is blocked. The probe runs at regular intervals; repeated failures trigger container restarts (liveness) or remove the pod from service (readiness).
How do I fix "getsockopt: connection refused"?
Health check probes fail because they cannot connect to the container on the specified port. The container may not be listening on that port, initialDelaySeconds is too low, or the container isn't starting properly. Fix by increasing initialDelaySeconds, verifying the port is correct, or checking why the application failed to start.
What causes "getsockopt: connection refused"?
initialDelaySeconds too low; probe runs before application starts listening Container listening on wrong port (e.g., 8080 but probe checks port 80) Application crashed before probe could connect
Is the "getsockopt: connection refused" 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