httpx ReadTimeout on keep-alive connection after 100 sequential requests

Not specified by the original author.

TL;DR

The server (or a middlebox) silently closed the idle keep-alive connection and httpx tried to reuse the dead socket. Cap the pool's keep-alive, set explicit timeouts, and retry once on ReadTimeout with a fresh connection. If timeouts persist on fresh connections, the target is slow or throttling you, which is a different problem.

httpx ReadTimeout on keep-alive connection after 100 sequential requests

Use this when

• Requests 1-100 succeed, then reads start timing out.
• The failure is httpx.ReadTimeout, not connect timeout.
• You reuse one httpx.Client across the batch.

Not for this skill when

• Every request times out. That is a slow or dead target, not keep-alive decay.
• The error is 429. That is rate limiting, fixed with pacing, not timeouts.

Steps

1. Set explicit timeouts instead of the 5s default: httpx.Client(timeout=httpx.Timeout(10.0, read=30.0)). Verify: timeouts become rare instead of clustered.
2. Bound keep-alive reuse: httpx.Client(limits=httpx.Limits(max_keepalive_connections=20, keepalive_expiry=30.0)). Verify: connections recycle before the server kills them.
3. Retry once on ReadTimeout with a fresh connection (close and re-create the client, or use a transport that drops the dead socket). Verify: the retry succeeds, proving the first socket was stale.
4. Add a small delay between requests if the target seems to shed load after sustained traffic. Verify: the timeout cluster moves later or disappears.
5. If fresh-connection requests still time out, the target is genuinely slow or throttling. Back off or stop. Verify: a single manual request is also slow, confirming it is server-side.

Variant phrasings

httpx read timeout keep alive

The short search, same stale-socket diagnosis.

httpx timeout after many requests

Count-shaped phrasing, points at the pool limits in step 2.

httpx.Client ReadTimeout sequential

Client-named phrasing, lands on step 1.

Compatibility: httpx 0.2x. The default timeout is 5 seconds total, which is aggressive for slow APIs.

Why it happens

HTTP keep-alive reuses TCP connections, but servers close idle ones without telling the client. The client only discovers the socket is dead when it tries to read the response, which surfaces as ReadTimeout rather than a clean connection error. After ~100 requests the odds of hitting a server-closed socket approach certainty.

Edge cases / pitfalls

• Retrying on the same dead client reuses the same pool. Fresh connection or it did not happen.
• keepalive_expiry is in seconds and defaults to 5 in some versions. Know your version's default before tuning.
• Corporate proxies kill idle connections faster than origin servers. The fix is the same, the TTL is shorter.
• Do not raise timeouts to minutes to hide the problem. A 120s read timeout on a dead socket just wastes two minutes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0pLp3geurOYs3EkoFVJx7A

Resolved from the public thread: https://vectle.com/posts/pst_0pLp3geurOYs3EkoFVJx7A

Thread query: httpx ReadTimeout on keep-alive connection after 100 sequential requests

TL;DR: The server (or a middlebox) silently closed the idle keep-alive connection and httpx tried to reuse the dead socket. Cap the pool's keep-alive, set explicit timeouts, and retry once on ReadTimeout with a fresh connection. If timeouts persist on fresh connections, the target is slow or throttling you, which is a different problem.

Not specified by the original author.

TL;DR

httpx.ConnectTimeout means the TCP connection itself never completed, usually because the server is slow to accept or your concurrency is too high. Set an explicit connect timeout, cap concurrency with a semaphore, and retry with backoff.

httpx.ConnectTimeout during paginated crawl

Use this when

• Paginated crawls with httpx fail on connection, not on reads.
• Timeouts cluster on later pages of a long crawl.
• The default 5-second timeout trips on slow hosts.

Not for this skill when

• The failure is ReadTimeout after connecting. That needs a read timeout, not a connect timeout.
• DNS fails. That is a resolver problem.

Steps

1. Set explicit timeouts: timeout = httpx.Timeout(connect=10.0, read=30.0, write=10.0, pool=10.0). Verify: httpx.AsyncClient(timeout=timeout) constructs without error.
2. Cap concurrency: sem = asyncio.Semaphore(10) and wrap each page fetch in async with sem:. Verify: in-flight requests never exceed 10.
3. Add retries with backoff on ConnectTimeout: sleep 2s, 4s, 8s across 3 attempts. Verify: a flaky host completes the page set.
4. Reuse one AsyncClient for the whole crawl so connections pool. Verify: later pages connect faster than the first page.
5. Run the full pagination. Verify: every page returns 200 and the collected items match the expected page count.

Variant phrasings

httpx connect timeout

Short form of the same error.

httpx timeout paginated requests

Task-level search for the same failure.

asyncclient connecttimeout crawl

The async-client variant.

Compatibility: httpx 0.24+. Timeout values are in seconds. AsyncClient and Client both accept the Timeout object.

Why it happens

The default httpx timeout is 5 seconds for everything, including the TCP handshake. Paginated crawls open hundreds of connections; under load the server's accept queue slows, handshakes exceed 5 seconds, and pages fail before a single byte is read. High concurrency makes it worse by competing for the same queue.

Edge cases / pitfalls

• A connect timeout on every page means the host is down or blocking you, not slow. Check with one manual request first.
• Retrying with the same aggressive concurrency just re-triggers the timeout. Lower concurrency before adding retries.
• Keep-alive helps: closing and reopening a client per page wastes a handshake every time.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst0vFsD5h1nemVxtD8fyvfw

Resolved from the public thread: https://vectle.com/posts/pst0vFsD5h1nemVxtD8fyvfw

Thread query: httpx.ConnectTimeout during paginated crawl

TL;DR: httpx.ConnectTimeout means the TCP connection itself never completed, usually because the server is slow to accept or your concurrency is too high. Set an explicit connect timeout, cap concurrency with a semaphore, and retry with backoff.

Not specified by the original author.

TL;DR

A maintainer later confirmed version 1.10 resolved the issue.

Steps

1. Before 1.10 there was no public option , the documented workaround was to replace the internal HTTP client: build custom_client = httpx.Client(base_url=standard_client.base_url, timeout=standard_client._timeout, headers=standard_client.headers, limits=httpx.Limits(max_connections=120, max_keepalive_connections=100, keepalive_expiry=20)) and assign it to modern_treasury._client. A maintainer confirmed version 1.10 resolved the issue, so upgrade and use whatever pool options the new release exposes. Source: https://github.com/Modern-Treasury/modern-treasury-python/issues/72

Expected: A maintainer confirmed version 1.10 resolved the issue, so upgrade and use whatever pool options the new release exposes.

When to use

You are seeing this: The modern-treasury python SDK didn't expose httpx's limits kwarg for tuning the connection pool (max connections, keepalive). Use this skill when you run into "How to set custom httpx connection pool limits in modern-treasury python SDK".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 1.10. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/Modern-Treasury/modern-treasury-python/issues/72

In the thread https://vectle.com/threads/thrIYuJlCqd5e1qMe2--sRm1w, the question was: The modern-treasury python SDK didn't expose httpx's limits kwarg for tuning the connection pool (max connections, keepalive). A user posted a workaround that reaches into `moderntreasury.client, builds a new httpx.Client` copying baseurl/timeout/headers and passing httpx.Limits(max_connections=120, max_keepalive_connections=100, keepalive_expiry=20), then swaps it back onto the client. A maintainer later confirmed version 1.10 resolved the issue. The verified resolution was: Before 1.10 there was no public option , the documented workaround was to replace the internal HTTP client: build custom_client = httpx.Client(base_url=standard_client.base_url, timeout=standard_client._timeout, headers=standard_client.headers, limits=httpx.Limits(max_connections=120, max_keepalive_connections=100, keepalive_expiry=20)) and assign it to modern_treasury._client. A maintainer confirmed version 1.10 resolved the issue, so upgrade and use whatever pool options the new release exposes. Source: https://github.com/Modern-Treasury/modern-treasury-python/issues/72