Java SocketTimeoutException: Read timed out

Diagnose Java java.net.SocketTimeoutException Read timed out by measuring server latency, reviewing timeouts, and fixing pool or keep-alive reuse.

intermediatedebuggingjavanetworktimeout

Symptoms

java.net.SocketTimeoutException: Read timed out
Requests intermittently fail under load or after idle periods
A connection pooled and reused later fails on first read

Possible causes

The server genuinely exceeds the configured read timeout
A stale idle connection in the pool was closed server-side
A proxy or load balancer drops idle keep-alive connections
The read timeout is too aggressive for the operation

Diagnosis steps

Measure server-side latency for the same operation

Interpretation

If the server consistently exceeds the client timeout, raise it or optimise the endpoint.

Check for idle-connection reuse failures

enable pool validation on borrow

Interpretation

Timeouts only after idle periods point to stale keep-alive connections.

Compare connection and read timeouts

Interpretation

A short read timeout with a long operation causes frequent failures unrelated to the network.

Root cause

SocketTimeoutException means the socket connected but no data arrived within the read timeout. The connected socket proves routing works, so the cause is server slowness, a stale pooled connection that the server silently closed, or an idle proxy breaking keep-alive.

Fix

Set both connect and read timeouts deliberately and size them to the operation. Enable pool validation and evict idle connections before the server or proxy closes them. For long operations, raise the read timeout or switch to streaming. Add retries for idempotent requests so transient slowness does not fail the call.

Verify the fix

Repeat the workflow after tuning; requests complete within the timeout and the intermittent read timeouts disappear across idle and loaded conditions.

Symptoms

Calls fail with java.net.SocketTimeoutException: Read timed out after a successful connect. Failures cluster after idle periods or at peak load, and a retry often succeeds.

Diagnosis

Measure server latency and inspect pool behaviour:

conn.setConnectTimeout(2000);
conn.setReadTimeout(5000); // too low for a slow endpoint?

Timeouts only after idle strongly suggest stale pooled connections.

Fix

Tune timeouts and validate pooled connections:

RequestConfig cfg = RequestConfig.custom()
    .setConnectTimeout(2000)
    .setSocketTimeout(15000)
    .setConnectionRequestTimeout(2000)
    .build();

Evict idle connections before the server or proxy closes them, and retry idempotent calls.

Verification

Re-run the load and idle scenarios; requests finish within the timeout and the intermittent read-timeout failures no longer appear.

Distinguishing the Subtypes

The exception message sometimes carries more detail: Read timed out means data never arrived, while connect timed out means the handshake never completed. Treating them separately shortens the investigation, because a connect timeout points at routing or an overloaded listener, whereas a read timeout points at application latency or stale pool entries. Capture both the connect and read timeouts in logs alongside the endpoint so a spike can be attributed without guesswork, and consider a separate, longer read timeout only for known slow operations rather than globally.