Proxy plans often advertise a limit such as 10, 100, or unlimited concurrent sessions. The number sounds straightforward, but the word “session” does not have one universal meaning.
Depending on the service architecture, a session may refer to an active TCP connection, proxy tunnel, sticky routing assignment, or authenticated communication channel. Understanding what the provider counts is essential before estimating capacity or diagnosing connection failures.
What exactly is a concurrent proxy session?
A concurrent proxy session is one proxy connection or routing context that remains active at the same time as other sessions.
Suppose an application opens 20 proxy connections and all of them are still active. The workload is using 20 concurrent sessions. If 10 connections finish while 10 remain open, concurrency falls to 10.
A session normally begins when the client establishes an accepted proxy connection or routing context. It ends when the connection closes, expires, times out, or is released by the application.
The provider may count any of the following as one session:
| Possible counting unit | When it may apply |
|---|---|
| Active TCP connection | HTTP, HTTPS, or SOCKS5 connection-based services |
| Proxy tunnel | Traffic sent through a persistent gateway |
| Sticky routing assignment | One session identifier mapped to a selected exit IP |
| Authenticated channel | A connection established with proxy credentials |
| Active port allocation | Port-based proxy plans |
| HTTP stream | Some multiplexed or gateway-based implementations |
This variation is why “100 concurrent sessions” should not automatically be interpreted as 100 simultaneous requests or 100 different IP addresses.
The exact counting rule should answer three questions:
- What event creates a session?
- What keeps the session active?
- What event releases it?
If those rules are unclear, capacity estimates can be wrong even when the advertised concurrency limit appears sufficient.
How is concurrency different from requests, connections, and IPs?
Concurrency measures simultaneous activity, while the other terms describe volume, transport, or routing identity.
| Term | What it measures | Example |
|---|---|---|
| Concurrent sessions | Active proxy sessions at one moment | 50 sessions currently open |
| Requests per second | Request throughput over time | 100 requests completed each second |
| Total requests | Accumulated work | 1 million requests during a job |
| Connections | Transport links between client, proxy, and target | 20 persistent TCP connections |
| Threads or workers | Application execution units | 10 workers processing tasks |
| Exit IPs | Addresses used to reach the destination | 30 observed IPs during a collection run |
| Bandwidth | Data transferred per second | 100Mbps of active traffic |
One session may process several requests when connection reuse is enabled. A sticky session may also send many sequential requests through the same exit IP. Conversely, one business task can create several concurrent sessions when it downloads multiple resources in parallel.
An application with 100 workers does not necessarily use 100 sessions. Each worker might open several connections, reuse one persistent connection, or remain idle without consuming a session.
The difference is especially important with HTTP keep-alive and HTTP/2:
- Keep-alive allows several sequential requests to reuse one connection.
- HTTP/2 can carry multiple request streams over one connection.
- Sticky routing preserves an exit IP but may still involve more than one transport connection.
- Per-request rotation may change the exit IP without changing the application’s worker count.
A concurrent-session limit therefore does not define request speed by itself. Throughput also depends on response time, connection reuse, bandwidth, target latency, and rate controls.
How many concurrent sessions does a workload need?
Required concurrency is mainly determined by request rate and how long each request remains active.
A useful starting estimate is:
Required concurrency ≈ requests per second × average request duration in secondsIf a website collection task sends 50 requests per second and each request takes an average of 0.8 seconds, estimated concurrency is:
50 × 0.8 = 40 concurrent sessionsIf the target slows down and average duration rises to 3 seconds, the same request rate may require:
50 × 3 = 150 concurrent sessionsNothing changed in the scheduler, but the slower responses kept sessions open longer. This is why concurrency-limit errors often appear during latency spikes.
A second estimate can be used when the application is organized around workers:
Peak concurrency ≈ active workers × connections per workerThe estimate should then be adjusted for:
- Redirects and subrequests
- Connection pooling
- Sticky sessions
- Retries
- Long downloads
- Timeout duration
- Several target domains
- Idle persistent connections
Use p95 request duration rather than only the average when planning capacity. The average can hide a small group of slow requests that holds many sessions open.
A practical capacity plan keeps headroom instead of operating continuously at the session limit. Without headroom, a short latency increase or retry wave can exhaust every available slot.
Why are concurrent-session limits exceeded?
Session limits are usually exceeded because connections remain open longer or multiply faster than expected.
Common causes include:
- Excessive worker parallelism: Every worker opens several connections at once.
- Slow target responses: Requests remain active and accumulate.
- Long timeout settings: Failed connections occupy slots before being released.
- Immediate retries: New sessions are created before previous attempts fully close.
- Missing connection cleanup: Response bodies or sockets remain open.
- Uncontrolled connection pools: Each process maintains its own maximum independently.
- Multiple containers: A safe per-instance limit becomes unsafe after horizontal scaling.
- Long sticky sessions: Old assignments remain active after the business transaction ends.
The resulting symptoms depend on the service and client:
| Symptom | Possible explanation |
|---|---|
| New connections time out | All available session slots are occupied |
| Connections are refused | The gateway rejects activity beyond the limit |
| Latency rises sharply | Requests wait in an internal or application queue |
| Retry volume increases | Session exhaustion is being treated as a temporary network failure |
| Throughput stops growing | Concurrency has reached a bottleneck |
| Exit IPs appear underused | Session count is high even though route diversity is low |
The first corrective action is not necessarily purchasing more concurrency. Reduce the workload to one process and measure active connections, request duration, and cleanup behavior.
For a website collection task, use a shared semaphore or queue to cap simultaneous work across all workers. Public-opinion monitoring may need separate limits by target domain so one slow source does not consume the complete session budget. A cross-border logistics information query may reserve one sticky session for each active transaction and release it as soon as the transaction finishes.
A retry should enter the same concurrency queue as a new request. Allowing retries to bypass the queue can create a feedback loop in which session exhaustion causes more sessions to be opened.
How should concurrent sessions be configured and monitored?
Set the limit from measured peak demand, then control it centrally and monitor active use rather than worker count.
A reliable configuration process has five steps:
- Measure normal demand: Record request rate and p50, p95, and p99 duration.
- Identify the counting rule: Confirm whether the service counts connections, tunnels, sticky assignments, ports, or streams.
- Estimate peak concurrency: Use expected request rate multiplied by p95 duration.
- Add controlled headroom: Leave capacity for latency changes and limited retries.
- Enforce one global limit: Coordinate processes and containers through a shared queue or distributed limiter.
The following metrics reveal whether the limit matches the workload:
| Metric | What it reveals |
|---|---|
| Active sessions | Current use of the available capacity |
| Peak sessions | Whether short bursts approach the limit |
| Session duration | Whether connections remain open unexpectedly |
| Queue wait time | Whether tasks are waiting for free capacity |
| Requests per session | Whether connection reuse is effective |
| Retry ratio | Whether failed attempts are multiplying demand |
| Timeout rate | Whether slow sessions are blocking capacity |
| Session completion rate | Whether multi-step tasks finish successfully |
The correct limit depends on the workflow:
| Workload | Session strategy |
|---|---|
| Independent website pages | Use a bounded pool of reusable connections |
| Paginated collection | Keep one route for the page sequence |
| Public-opinion monitoring | Apply shared limits by target domain |
| Cross-border logistics queries | Assign one sticky session per active transaction |
| Large file collection | Reserve fewer, longer-lived sessions |
| Multi-container collection | Enforce concurrency across the entire deployment |
The practical rule is to treat concurrent sessions as a finite infrastructure resource. More sessions can increase throughput only until bandwidth, target latency, CPU, or request controls become the next bottleneck.
FAQ
Q: Is one concurrent session equal to one proxy IP?
No. A session describes active communication, while an IP describes the exit address. Several sessions may use the same IP, and one rotating configuration may use different IPs across the lifetime of a logical workload.
Q: Is one concurrent session equal to one request?
Not always. A persistent connection can carry several sequential requests, and some protocols can carry several streams over one connection. A single request can also create additional connections through redirects or related resource downloads.
Q: Do idle keep-alive connections count as concurrent sessions?
They may. Some services count a connection until it closes or reaches an idle timeout, even when no request is currently moving through it. Confirm the counting rule and close unnecessary idle connections.
Q: Will increasing concurrent sessions always improve speed?
No. Throughput stops improving when another bottleneck is reached. The limiting factor may become bandwidth, target response time, CPU, parser capacity, or an application-level request limit.
Q: What happens when the concurrency limit is reached?
New connections may be queued, delayed, refused, or allowed to time out. The exact behavior depends on the service and client. Monitoring should distinguish session exhaustion from DNS, authentication, and target-response failures.
Q: How much concurrency headroom is necessary?
There is no universal percentage. Base the buffer on p95 and p99 request duration, retry behavior, and expected traffic bursts. The goal is to absorb normal variation without leaving large amounts of paid capacity permanently unused.
