What Is Concurrent Sessions in Proxies? – Definition and How It Works
Learn what a proxy concurrent-session limit means, how it differs from bandwidth or request quotas, and how to plan for it.
A concurrent-session limit is the number of connections a proxy account may hold open at the same time. It caps parallelism directly, unlike a bandwidth or request quota, which caps volume over time.
1. Three Different Limits
| Limit | Constrains | Exceeded means |
|---|---|---|
| Concurrent sessions | Simultaneous connections | New connections refused or queued |
| Requests per period | Total volume | Throttled or billed |
| Bandwidth | Bytes transferred | Throttled or billed |
These are independent. A plan can allow generous bandwidth and only ten concurrent sessions, which limits throughput far more than the bandwidth figure suggests.
2. What Counts as a Session
The definition varies by provider, and it matters:
- One TCP connection to the proxy — the most common definition.
- One sticky session identifier, regardless of underlying connections.
- One authenticated tunnel, with multiplexed requests inside it.
The difference is significant. Under the first definition, connection pooling with keep-alive holds sessions open between requests, so a pool of 20 connections consumes 20 sessions even while idle.
That is the usual reason a client "exceeds" a limit it appears to be under: idle pooled connections still count.
3. What Happens at the Limit
Refused connections — an immediate error, which is the best case because it is visible.
Queued connections — the request waits, appearing as latency rather than as an error. Harder to diagnose, since the symptom is slowness.
Silent drops — a connection accepted and then closed, which surfaces as a reset or a timeout unrelated in appearance to any quota.
The middle case is the one that misleads: a pipeline that looks network-bound is actually waiting for a session slot.
4. Sizing Concurrency Around It
Throughput is roughly sessions / latency. With 10 sessions and 500 ms per request, the ceiling is about 20 requests per second — and no amount of client-side concurrency exceeds it.
So client concurrency should be set to the session limit, not above it. Setting it higher produces queueing or errors without any additional throughput, and makes failures harder to attribute.
from concurrent.futures import ThreadPoolExecutor
PROXY_SESSION_LIMIT = 10
with ThreadPoolExecutor(max_workers=PROXY_SESSION_LIMIT) as pool:
...
5. Sticky Sessions Consume the Budget
A sticky session holds one exit address for a period, which is required wherever a login or a multi-step flow must appear continuous.
The cost is that a sticky session occupies a slot for its whole duration, including the time your code spends parsing rather than requesting. Ten sticky sessions held for ten minutes each is your entire budget for ten minutes.
Practical consequence: release sticky sessions as soon as the flow that needed continuity is done, rather than holding them for the life of a worker.
6. Making the Most of a Small Limit
- Reuse connections within a session rather than opening new ones per request.
- Close sessions promptly, and set an idle timeout in your pool below the provider's.
- Batch where the target allows it — one request returning fifty results beats fifty requests.
- Reduce per-request time, since throughput is sessions divided by latency; halving latency doubles throughput at the same limit.
- Avoid browsers where possible. A page load opens many connections, and depending on the provider's counting, one page can consume several sessions.
- Use plain HTTP for what does not need rendering.
7. Monitoring It
Track concurrent sessions in use, not just request counts. The signals worth alerting on:
- Session-limit errors, at any rate above zero.
- Time spent waiting to acquire a session slot.
- Idle sessions held open, which is waste you can reclaim.
- Actual throughput against the theoretical ceiling — a large gap means slots are being held rather than used.
8. Summary
A concurrent-session limit caps simultaneous proxy connections, independently of bandwidth and request quotas, and it is frequently the real ceiling on throughput.
Set client concurrency to the limit rather than above it, remember that pooled idle connections and long-held sticky sessions consume slots while doing nothing, and monitor slot-acquisition wait time — because a pipeline blocked on sessions looks exactly like one blocked on the network.