A connection timeout is usually the network, the DNS, the firewall, the server, the application, or the load balancer. The fix is to find the actual timeout and address the cause, not to retry the connection.
Table of contents
- Check the network
- Check the DNS
- Check the firewall
- Check the server
- Check the application
- Check the load balancer
- FAQ
Check the network
The first thing to check: is the network up? The pattern: the user cannot reach the server, the network is down, and the connection times out.
The fix: test the network. ping or traceroute from a known-good location. If the network is up, the problem is not the network.
Check the DNS
The second thing to check: is the DNS resolving? The pattern: the user types a URL, the DNS resolver is down or slow, the connection times out.
The fix: time the DNS resolution. dig +short on Linux or nslookup on Windows. If the resolution fails, the problem is the DNS.
Check the firewall
The third thing to check: is the firewall blocking the connection? The pattern: the network is up, the DNS is resolving, the connection is blocked by a firewall (the server’s firewall, the cloud’s security group, the corporate network’s firewall).
The fix: check the firewall. On Linux, iptables -L or nft list ruleset. On the cloud, the security group. On the corporate network, the firewall configuration. The fix is usually to add a rule to allow the connection.
Check the server
The fourth thing to check: is the server up? The pattern: the network is up, the DNS is resolving, the firewall is allowing the connection, but the server is down or not listening on the port.
The fix: check the server. ping to verify the server is up, telnet server port or nc -zv server port to verify the port is listening. If the server is not listening, the problem is the server.
Check the application
The fifth thing to check: is the application responding? The pattern: the server is up, the port is listening, the connection is established, but the application is not responding.
The fix: check the application’s logs. The application should have logged the issue. The fix is in the application.
Check the load balancer
The sixth thing to check: is the load balancer the issue? The pattern: the server is up, the application is responding, but the load balancer is not routing the connection to the server.
The fix: check the load balancer’s target group. If the target group has no healthy targets, the problem is the targets, not the load balancer.
FAQ
Why is the connection to the server timing out?
Six common causes: the network is down, the DNS is not resolving, the firewall is blocking, the server is not listening, the application is not responding, the load balancer is not routing.
How do I diagnose a connection timeout?
Check the network. Check the DNS. Check the firewall. Check the server. Check the application. Check the load balancer. The answer is usually in one of those six places.
What is the most common cause of a connection timeout?
The firewall. The team that has set up a new server and forgotten to open the port in the security group is the team that has the most connection timeouts.
How do I fix a connection timeout?
Find the actual cause. The fix is in the network, the DNS, the firewall, the server, the application, or the load balancer. Retrying the connection is not a fix; it is a workaround.
What is the difference between a connection timeout and a read timeout?
A connection timeout happens before the connection is established. A read timeout happens after the connection is established but the server is not responding. The fixes are different.
How long should I wait for a connection timeout?
The default timeout in most clients is 30-60 seconds. The team that has a long-running operation should set the timeout to a longer value, but should also have a retry policy and a circuit breaker.
If you are sizing a server tier for a new project, the RunxBuild hosting calculator is the place to model the line items. The instances, the network, the storage, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual server health in one place.