Diagnose Connection Timed Out vs Connection Refused Errors

Understanding the difference between "Connection Timed Out" and "Connection Refused" errors is fundamental to network troubleshooting. These errors have completely different root causes, and knowing which one you're facing immediately narrows your investigation. This guide covers systematic diagnosis of both error types.

The Key Difference

• Connection Refused (ECONNREFUSED): A TCP RST packet was received — the server is reachable but nothing is listening on the port. The packet reached the destination and was rejected.
• Connection Timed Out (ETIMEDOUT): No response at all — the SYN packet went into a void. The server may be down, the port may be firewalled, or there's a routing problem.

Diagnosing Connection Refused

Connection Refused means the server's network stack is working, but no process is bound to the requested port.

Common Causes

1. The service is not running
2. The service is listening on a different port
3. The service is bound to localhost only (127.0.0.1) instead of all interfaces (0.0.0.0)
4. A firewall is sending RST packets (reject rule rather than drop rule)

Diagnosis Steps

# Step 1: Check if the service is running
sudo systemctl status nginx
sudo systemctl status your-app

# Step 2: Check what's listening on the expected port
sudo ss -tlnp | grep :80
sudo ss -tlnp | grep :443
# Look at the "Local Address" column:
# 0.0.0.0:80  = listening on all interfaces (correct)
# 127.0.0.1:80 = listening on localhost only (won't accept remote connections)

# Step 3: If bound to localhost, fix the service configuration
# For Node.js: listen on '0.0.0.0' instead of 'localhost'
# For Nginx: check the listen directive
# For Python: use host='0.0.0.0'

# Step 4: Check iptables for REJECT rules (these cause "refused")
sudo iptables -L -n | grep REJECT
# REJECT rules send RST, DROP rules cause timeout

Diagnosing Connection Timed Out

Connection Timed Out means the SYN packet never got a response. The problem is somewhere in the network path.

Common Causes

1. Firewall dropping packets (iptables DROP, security groups, cloud firewall)
2. Server is completely down or unreachable
3. Incorrect IP address or DNS resolution
4. Network routing issue between client and server
5. ISP-level blocking

Diagnosis Steps

# Step 1: Can you reach the server at all?
ping server-ip
# If ping fails: server might be down or ICMP blocked

# Step 2: Trace the network path
traceroute server-ip
mtr server-ip
# Look for where packets stop or have high loss

# Step 3: Check from the server itself
# If you have console access, check local connectivity
sudo ss -tlnp | grep :80  # Is the service listening?
curl localhost:80          # Can it reach itself?

# Step 4: Check firewall rules on the server
sudo iptables -L -n -v | grep DROP
sudo ufw status verbose
# Look for DROP rules on the target port

# Step 5: Check cloud provider firewall
# Security groups, network ACLs, or cloud firewall
# These operate outside the server's OS

# Step 6: Test from a different location
# Use an online tool or different server to rule out client-side issues
curl -v --connect-timeout 5 http://server-ip:80

Advanced Diagnosis with tcpdump

# On the server, capture traffic on the target port
sudo tcpdump -i any port 80 -n

# If you see SYN packets arriving but no SYN-ACK: firewall is dropping
# If you see SYN-ACK going out: server is responding but client isn't receiving
# If you see nothing: packets aren't reaching the server

# Capture to file for analysis
sudo tcpdump -i any port 80 -w /tmp/capture.pcap -c 100

# On the client side
sudo tcpdump -i any host server-ip and port 80 -n

Quick Reference Table

Best Practices

• Start with the error message: "Refused" and "Timed out" point to completely different problems
• Check locally first: Verify the service works on the server itself before investigating network issues
• Test from multiple locations: Rule out client-side issues by testing from different networks
• Use ss -tlnp (not netstat) for fast, detailed listening port information
• Remember cloud firewalls: Security groups and network ACLs are separate from iptables
• Check DNS: Ensure the hostname resolves to the correct IP address