Uncovering the Truth Behind Connection Reset: A Network Timeout Investigation

Two kinds of network timeout

java.net.ConnectException: Connection refused

– target port not open (connection stage) java.net.ConnectException: Connection timed out – network unreachable or firewall blocks (connection stage) java.net.SocketTimeoutException: Read timed out – server response too slow (data transfer stage) java.net.SocketException: Connection reset – peer closed the connection abruptly (data transfer stage)

Scenario 1 – Connect timed out

Symptom

java.net.ConnectException: Connection timed out

Common causes

Server not started

Firewall or security‑group blocking the port

Network unreachable

Incorrect IP or port configuration

Investigation steps

# 1. Test network reachability
ping 192.168.1.100

# 2. Test port availability
telnet 192.168.1.100 8080

# 3. If reachable, verify service health
curl http://192.168.1.100:8080/actuator/health

# 4. Check host firewall (Ubuntu/Debian)
ufw status

# 5. Check cloud security‑group via console

Scenario 2 – Read timed out

Symptom

java.net.SocketTimeoutException: Read timed out

Common causes

Server processing slowly (e.g., slow SQL)

Large response payload

Timeout setting too short

Server Full GC pauses

Investigation steps

# 1. Log execution time on the server (add timing logs)

# 2. Check MySQL slow queries
mysql -u root -p -e "SHOW SLOW LOG;"

# 3. Inspect GC activity
jstat -gcutil <PID> 1000

# 4. Verify timeout values in configuration
cat application.yml | grep -i timeout

Client configuration (Spring Boot)

@Bean
public RestTemplate restTemplate() {
    return new RestTemplateBuilder()
        .setConnectTimeout(Duration.ofSeconds(3))
        .setReadTimeout(Duration.ofSeconds(10)) // read timeout
        .build();
}

Scenario 3 – Connection reset

Symptom

java.net.SocketException: Connection reset

Common causes

Server actively closes the connection

Server crash or OOM

Firewall / load‑balancer timeout

Network instability

Investigation steps

# 1. View server logs
tail -f logs/app.log

# 2. Look for OOM events
dmesg | grep -i "out of memory"

# 3. Review load‑balancer timeout configuration
# Nginx: proxy_read_timeout 60s
# ALB: idle timeout

# 4. Capture packets for analysis
tcpdump -i eth0 port 8080 -w dump.pcap

Server‑side specific reasons

Code calls response.getWriter().close() or closes socket abruptly

Firewall / load balancer timeout, e.g., Nginx proxy_read_timeout 60s cuts the connection if processing exceeds 60 seconds, causing the client to receive

Connection reset

Comprehensive case study

Symptom

An interface intermittently throws Read timed out while server logs show the request finished in 200 ms.

Investigation process

Checked client configuration – RestTemplate had no timeout set, so defaults were infinite.

Found occasional server Full GC pauses (1‑2 s). The client’s default timeout (a few seconds) expired during those pauses, producing intermittent timeouts.

Solution

@Bean
public RestTemplate restTemplate() {
    return new RestTemplateBuilder()
        .setConnectTimeout(Duration.ofSeconds(5))
        .setReadTimeout(Duration.ofSeconds(30)) // enlarge read timeout
        .build();
}

Optimized server GC to reduce Full GC frequency.

Quick‑reference troubleshooting tools

ping

– test network reachability telnet – test if a port is open nc – test port and send data curl -w – view HTTP response timing tcpdump – capture packets for analysis ss -tuln – list listening ports

Final guidance

Identify the stage at which the timeout occurs:

Cannot connect → examine network, firewall, and service startup.

Connected but no response → inspect server processing, payload size, and timeout settings.

Connection reset → check middleware timeouts and whether the server closed the connection.

Start with telnet <host> <port> to pinpoint the problematic phase.