🚨 Linux Error: Connection timed out — Cause, Fix, and Troubleshooting Guide

Summary

Connection timed out is errno ETIMEDOUT (110): the client sent TCP SYNs and never got a reply, so the kernel gave up after retransmitting. Unlike Connection refused (an instant RST), a timeout means packets are being silently dropped somewhere — by a firewall, security group, missing route, or a host that is down. The tell-tale sign is the long delay before the error.

Common Symptoms

• The client hangs for many seconds (often ~15–130s) before failing, not instantly.
• curl -v sits at Trying <ip>:<port>... and then times out.
• Some ports/hosts work while this one hangs — pointing at a per-port firewall rule.
• Intermittent timeouts under load (overloaded backend, dropped SYNs, or asymmetric routing).

Most Likely Causes of the ‘Connection timed out’ Error

1. Firewall / security group dropping (DROP) the packets — cloud security groups, iptables -j DROP, or an on-path appliance.
2. The remote host is down or the service is hung — SYNs go unanswered.
3. Routing problem / wrong route — packets leave but never reach the destination, or replies cannot return.
4. Wrong IP or a NAT/loadbalancer black-holing traffic.
5. Network congestion / packet loss causing SYN loss under load.
6. Server backlog full — the listen queue is saturated and drops new SYNs.

Quick Triage

# Note the delay: a long hang = timeout (dropped), instant = refused
time curl -v --connect-timeout 5 http://<host>:<port>/

# Does the port respond within a bound?
nc -vz -w 5 <host> <port>

# Basic reachability of the host itself
ping -c3 <host>

Diagnostic Commands

# Time-bounded probes so you are not waiting on the default 2-min timeout
nc -vz -w 5 <host> <port>
curl -v --connect-timeout 5 http://<host>:<port>/

# Is the destination even routable, and via which interface/gateway?
ip route get <host-ip>
ip route

# ICMP reachability (may itself be filtered, but a useful signal)
ping -c3 <host>

# Resolve first — make sure you are timing out against the right IP
getent hosts <host>

# On the SERVER: is it listening and is the backlog overflowing?
ss -tulpn | grep ':<port>'
ss -s                              # summary incl. socket states
netstat -s | grep -i 'listen'      # SYN/listen-queue drops (RHEL/older)

# Local firewall on client or server
sudo iptables -S | grep -iE 'drop|reject'
sudo nft list ruleset 2>/dev/null | grep -i drop
sudo firewall-cmd --list-all       # RHEL/Rocky
sudo ufw status verbose            # Ubuntu/Debian

# Trace the path to find where packets die
traceroute -T -p <port> <host>     # TCP traceroute to the service port
mtr -rw <host>

If ip route get picks an unexpected interface/gateway, or traceroute dies at a hop, the drop is in the network path, not the service.

Fix / Remediation

1. Open the port in the firewall / security group. For cloud hosts, add an inbound rule for the port/source in the security group first — this is the most common cause. On the OS firewall:

   sudo ufw allow from <src-cidr> to any port <port> proto tcp   # Ubuntu/Debian
   sudo firewall-cmd --add-port=<port>/tcp --permanent && sudo firewall-cmd --reload   # RHEL/Rocky

2. Confirm the service is up on the server (a hung/dead service also times out if the firewall silently drops, or if it never accepts):

   ssh <server> 'ss -tulpn | grep ":<port>"; systemctl status <service>'

3. Fix routing if ip route get shows the wrong path:

   ip route get <host-ip>
   sudo ip route add <net>/<mask> via <gateway> dev <iface>     # add/repair a route

   Warning: Editing routes or firewall rules on a remote host can cut off your own SSH session. Have console/out-of-band access ready, or use a scheduled iptables-restore/timeout to auto-revert before applying risky changes.

4. Increase server backlog if ss -s/netstat -s shows SYN queue drops under load:

   sudo sysctl -w net.core.somaxconn=1024
   sudo sysctl -w net.ipv4.tcp_max_syn_backlog=2048

   (and raise the app’s own listen() backlog to match).

5. Correct the target IP/hostname if you are timing out against a stale or wrong address.

Validation

nc -vz -w 5 <host> <port>                    # succeeds quickly
curl -sS -o /dev/null -w '%{http_code} %{time_connect}s\n' --connect-timeout 5 http://<host>:<port>/
traceroute -T -p <port> <host>               # reaches the destination

Prevention

• Codify firewall/security-group rules (IaC) and review them so a port drop is caught in change control.
• Always set explicit --connect-timeout/socket timeouts and retries in clients so a drop fails fast instead of hanging.
• Monitor SYN-queue drops (netstat -s) and connection latency; alert on rising time_connect.
• Use TCP health checks from monitoring to detect black-holed paths before users do.

Related Errors

• Connection refused
• No route to host
• Network is unreachable
• Destination host unreachable
• Temporary failure in name resolution

Final Notes

The long delay is the diagnostic: a timeout means packets are dropped silently, so look at firewalls, security groups, and routing rather than the service config. Bound your probes with -w/--connect-timeout, use TCP traceroute to find where packets die, and remember that a cloud security group is the single most common culprit.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.