Concurrent Connection Limits
A concurrent connection limit is the maximum number of connections a proxy service allows at the same time. It determines how much work you can run in parallel through an account, a package, or an individual proxy IP. It is one of the Proxy Usage Limits that can affect an otherwise working, paid service.
Proxy plans use labels such as connections, threads, sessions, and concurrency for limits that do not always count the same thing. A large IP list or unlimited traffic allowance does not tell you how many browser profiles or scraping jobs the service can handle simultaneously.
That distinction becomes expensive when a small test works perfectly, but a full launch produces failed connections. The IPs may still be working. The software may simply be asking for more simultaneous capacity than the plan provides.
Threads and connections
A thread or worker setting describes how your software organizes its work. A connection is an open network channel. The two counts can differ considerably.
For a browser task, opening one product page can trigger requests for images, scripts, fonts, analytics, and data from several domains. One browser profile can therefore use several connections through its proxy. Opening many profiles together can create a much larger peak than their later, mostly idle activity.
The opposite is possible too: one application thread can manage many asynchronous network requests. A Python or Node.js program does not need a separate operating-system thread for every connection it opens.
“100 threads” in a scraping tool is not a reliable promise of “100 connections” at the proxy. The mapping depends on what each worker does and how the client handles networking.
There is no fixed allowance of 30, 50, or 80 connections per browser tab. A request for every page resource does not necessarily open a new connection: connections can be reused, and HTTP/2 can carry several requests simultaneously through one connection. A browser network panel showing 80 requests therefore does not establish that the proxy counted 80 concurrent connections.
What the provider actually counts
Some services count open connections. Others describe their limit as the number of requests being processed at the same time. Those definitions matter when connections remain open between requests or several requests share one connection.
| Plan parameter | What it measures |
|---|---|
| Concurrent connections | Connections open at the same time |
| Concurrent requests | Requests being handled at the same time |
| Requests per second, or RPS | How many requests are sent or processed each second |
| New connections per second, or CPS | How quickly new connections are established |
| Bandwidth, in Mbps | The rate at which data can be transferred |
| Traffic allowance, in GB | Data transferred over the billing period |
A 500-connection limit does not mean 500 requests per second or 500 requests for the month. When an occupied connection is closed and removed from the count, its place becomes available again. You do not need to wait for the next billing cycle.
Likewise, a service can permit many existing connections while limiting how quickly new ones are created. Reopening a connection for every small request can run into that second limit even when the simultaneous count remains modest.
An account limit and an IP limit are different purchases
The scope of the limit is as important as its size. These are two documented market arrangements: 500 simultaneous requests across a paid account, and 100 simultaneous sessions per dedicated datacenter IP. They are examples of different products, not standard allowances for all providers.
An account-wide limit is shared by every application, server, and team member using that account. If four programs each try to maintain 300 counted connections, their combined demand is 1,200. Giving each program different proxy IPs does not change an account-wide cap.
A per-IP limit works differently. With 100 IPs allowing 100 connections each, the arithmetic maximum is 10,000 connections spread across the addresses, subject to any additional account or infrastructure limits. It does not permit 10,000 connections through one IP. Unused capacity on another address does not automatically increase the busy address's allowance.
Packages and sub-users may have their own quotas as well. Sub-users can divide existing capacity between projects without increasing the total. A second login is not automatically a second allocation.
A limit can also apply to a particular connection endpoint, written as a host and port. In a modem-based service, that endpoint may provide access to one modem. It can still be subject to an additional account-wide limit.
There can also be a separate restriction on the customer's source IPs. A plan may allow unlimited sessions from one network but require an extra option to use the same proxy simultaneously from a home connection and a VPS. The number of devices allowed to connect is a different question from the number of connections they can open.
Why a slower website uses more capacity
A connection waiting for a response can still occupy a place. If a target website slows down while the program keeps starting new work at the same rate, unfinished requests accumulate.
A useful estimate is:
Average active requests ≈ requests started per second × average request duration in seconds.
The following is a calculation example, not a provider benchmark. It assumes a sustained rate of 100 requests per second and a system able to keep up.
| Average request duration | Average requests in progress |
|---|---|
| 0.5 seconds | 50 |
| 2 seconds | 200 |
| 5 seconds | 500 |
Where each active request occupies a separate counted connection, the figures also approximate the connections needed. With multiplexing or idle open connections, the two counts will differ.
This explains why unchanged software can suddenly reach its limit. A slower website, a large response, or a long wait for a timeout keeps work in progress for longer. If the program has a fixed parallelism setting instead, the same slowdown usually reduces completed requests per second.
The calculation describes an average, not the peak. Starting many browsers together or retrying failed jobs in a batch can briefly demand much more capacity.
Open connections after a task finishes
HTTP keep-alive allows a client to reuse a connection for later requests. Reuse saves connection setup work, but an idle connection may still count if the provider limits open connections. The idle timeout depends on the client and service; there is no universal 5–15 second lifetime.
Several timeout settings serve different purposes. An idle timeout limits inactivity; a maximum session duration limits total connection lifetime. A connect timeout usually limits the wait to establish a connection. An interrupted client may also leave server-side state until the service detects the disconnect or a timeout expires.
An application can keep connections occupied accidentally. With streamed responses in Python Requests, for example, the connection is not released back to the pool until the response body has been consumed or the response has been closed. Repeatedly leaving responses unfinished can exhaust the client's available connections.
Turning off reuse everywhere is not a universal remedy: it creates more connection setup and may increase the rate of new connections. The useful combination is a bounded connection pool, sensible timeouts, and responses that are properly completed or closed.
Datacenter, ISP, residential, and mobile plans
The source of a proxy IP does not define its connection allowance. Each product combines access to addresses with a particular allocation of service capacity.
Datacenter and ISP proxies may have a limit per IP, per package, or across the account. Unlimited traffic can coexist with any of these. A dedicated address gives you the stated exclusivity of the IP; it does not necessarily give you a dedicated server or unlimited connections. IPv6's large address space does not remove gateway or server limits either.
Residential pools can offer high or unlimited advertised concurrency, particularly with traffic-based billing. That allowance describes the service's permitted workload, not the capacity of one household connection. A large distributed pool and a single sticky exit are different resources. Holding the same IP does not make that exit capable of handling an arbitrary workload.
Mobile services need a further distinction. A distributed pool uses many cellular exits. Renting access to one modem places traffic through a particular cellular connection, with its own radio conditions, available bandwidth, and carrier restrictions. More simultaneous transfers share that connection. There is no universal limit of 1–50 connections that describes every mobile product.
Even within one provider, a free test, a paid proxy plan, and a managed scraping API can have different concurrency limits. A restricted trial may demonstrate compatibility without demonstrating the full capacity of the paid service.
When unlimited traffic comes with fewer connections
Concurrency can change during the subscription. Some fair-use arrangements reduce parallelism after a traffic threshold instead of disabling the proxy completely.
One documented dedicated datacenter arrangement allows 100 sessions per IP, then reduces that IP to 10 after it transfers 100 GB during the billing cycle. The lower allowance remains until the cycle ends. This is a product-specific rule, but it shows how a working proxy can become much less suitable for a previously successful workload.
Speed reduction is a separate control. Fewer connections restrict how much can run in parallel; lower bandwidth restricts how fast data can move. A provider can apply either or both. Slow transfers alone do not identify which restriction is active.
What exceeding the limit looks like
An explicit concurrency error is the clearest signal. A provider may return HTTP 429 together with a message identifying the account's connection limit. Other implementations reject new connections or leave the client waiting until its connection attempt times out. There is no universal promise that excess requests will be placed in an orderly queue.
The familiar error codes need context:
| Symptom | What it can establish |
|---|---|
| A provider message explicitly naming concurrency | Strong evidence that the stated service limit was reached |
| HTTP 429 without that explanation | A rate or workload restriction, potentially imposed by the target website |
| HTTP 502 or 503 | A gateway or service problem; the code alone does not identify a connection limit |
| Connection refused, reset, or timeout | A connection failure that also has several possible network and server causes |
If a target website is issuing the restriction, buying more concurrency at the proxy provider does not remove the website's rule. The source and wording of the error matter more than the number alone.
Reaching a connection cap is also different from an account suspension. New work may fail while existing work continues. Repeated overload can have further consequences under the service's rules, but a single concurrency error does not itself mean the account has been banned.
Limits inside the software and infrastructure
The provider's allowance is only one ceiling. The application may impose a lower one: aiohttp's standard connector defaults to 100 simultaneous connections in total, while Scrapy's default global setting is 16 concurrent requests. Additional per-host settings or delays can reduce actual activity further.
On servers, open sockets also consume operating-system resources. File-descriptor limits, memory, connection tracking, and gateway configuration can constrain the workload. A traditional TCP proxy generally maintains a client-facing connection and a target-facing connection for a tunnel; the customer-facing allowance is not simply the server's file-descriptor count.
One listening port, such as 1080, can accept many connections. Connections are distinguished by both endpoints' addresses and ports. The existence of 65,535 possible nonzero port numbers does not create a universal 65,535-connection allowance for every proxy IP.
Authentication and protocol labels do not supply a reliable shortcut. Username–password authentication does not by itself require decrypting the content of the websites being visited. IP allowlisting can simplify some checks, but the actual capacity depends on implementation and the plan. SOCKS5 is not automatically more expensive in memory than an HTTP CONNECT tunnel carrying the same long-lived traffic.
Getting useful capacity from the plan
Where the dashboard provides an active-connection or active-request counter, its scope should match the quota being assessed. An account-wide counter includes work from other machines. A local socket count can help investigate one client, but it will not reproduce a provider's active-request counter exactly. Brief peaks also matter: an hourly average can hide the burst that caused failures.
For a browser workload, sizing starts with its observed peak usage on the intended sites. If a profile reaches 12 counted connections and the account allows 500, dividing gives about 41 profiles as a theoretical ceiling for that example. Other activity and uneven peaks mean the operating number needs room below it. Dividing every plan by a fixed 30 or 50 ignores how the actual pages behave.
Where the task allows it, blocking unnecessary images, video, fonts, or tracking requests can reduce traffic and network work. Blocking page scripts or styles can also change rendering and break the task. Resource filtering should be checked against the result you need; it does not guarantee that every browser will use only one or two connections.
For HTTP clients, control both active work and the connection pool. A pool setting is not always a hard concurrency cap in every library. When several processes share one account, their combined budget matters. A local limit of 500 in each of four processes is still a potential demand of 2,000.
Retries belong within that same budget. Increasing delays between attempts, adding a small random delay, respecting Retry-After when present, and bounding the number of retries help avoid synchronized bursts. Repeating a state-changing action also needs care: a timeout does not prove that the first attempt did nothing.
The useful performance measure is successful work completed per second alongside latency and errors. If increasing workers raises failures without improving completed work, more parallelism is no longer helping.
When a larger plan helps
A larger plan helps when it increases the capacity that actually limits the job. Additional IPs can help with a per-IP cap if the workload can be distributed. A higher account-wide allowance can help several programs sharing one quota. Neither change fixes a lower limit in the client or creates extra capacity in a saturated cellular connection.
Rotating an exit IP, changing a sticky-session identifier, or switching proxy protocols does not automatically increase the account allowance. Replacing addresses while the same shared limit remains in place can leave the original problem untouched.
The purchase decision comes down to what is counted, where the limit applies, and whether it stays the same throughout the billing period. Those details determine whether the service can support the workload you intend to run, even when its IP count and traffic allowance already look sufficient.