How to fix getsockopt: connection refused in Kubernetes
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- Increase initialDelaySeconds
- Verify the port is correct
- Check if container is actually listening
- Ensure application listens on 0.0.0.0, not 127.0.0.1
livenessProbe:httpGet:path: /healthport: 8080initialDelaySeconds: 60 # IncreasedperiodSeconds: 10failureThreshold: 3getsockopt: 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
- 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
- Container not bound to 0.0.0.0:port; only listening on 127.0.0.1
- Network policies or firewalls blocking access to container port
- Insufficient resources preventing application startup
- Wrong probe path or missing health endpoint
How to fix "getsockopt: connection refused"
Default (0) is usually too low. Allow time for startup:
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 60 # Increased
periodSeconds: 10
failureThreshold: 3Check what port the application listens on:
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.
Exec into the container and verify:
kubectl exec -it <pod-name> -n <namespace> -- netstat -tulpn | grep LISTEN
# Or
kubectl exec -it <pod-name> -n <namespace> -- ss -tulpnLook for the port the probe is checking.
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.
View full logs to find startup errors:
kubectl logs <pod-name> -n <namespace> --tail=100
kubectl logs <pod-name> -n <namespace> --previous # Previous restartAdvanced 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
- 📚Kubernetes Official Documentation
- 📖Kubernetes Docs: configure liveness readiness startup probes(Official Docs)
- 📖Kubernetes Docs: debug running pod(Official Docs)
- 💬Stack Overflow: liveness and readiness probe connection refused(Stack Overflow)