Phrases you often see in proxy plans such as "50K connections" or "100 concurrent threads" all describe one thing: the number of TCP connections you can keep open at the same time. This limit directly determines how fast you can work, and when it is exceeded the error messages are often misleading.
In this article we cover what concurrency is, how the right number is calculated and how to diagnose exceeding the limit.
Concurrency and Request Rate Are Not the Same Thing
The two concepts are constantly confused:
The simple form of Little's law: request rate = concurrency ÷ average request duration. If you have 20 concurrent connections and each request takes 500 ms on average, you can send 40 requests per second. If the request duration rises to 2 seconds, at the same concurrency you can send only 10 requests per second.
A slow proxy slows your work down without increasing concurrency. That is why latency is often more decisive than the concurrency limit.
Where Is the Limit Applied?
The concurrency limit exists not in one place but at several points in the chain at once:
Opening 200 threads on your side is of no use if the provider caps you at 50; the excess waits in the queue or errors out.
Signs of Exceeding the Limit
When you exceed the concurrency limit, you do not get a clear "limit exceeded" message. The typical symptoms are these:
A critical distinction: 429 comes from the target, connection resets from the proxy, and EMFILE from your own machine. All three require different solutions.
How to Find the Right Concurrency
An experimental approach is more reliable than a theoretical calculation. Apply a staged load test:
Start low
Send 200 requests with 5 concurrent connections. Record the average duration and the success rate.
Double it
Proceed as 10, 20, 40, 80… Repeat the same measurement at every step.
Find the breaking point
The moment total throughput (requests/sec) stops increasing and the average duration starts to rise, you are near the real limit.
Run at 70% of it
Use roughly 70% of the breaking point as your production value. This margin protects against fluctuations during the day.
The throughput curve flattens between 40 and 80 while latency shoots up. Beyond this point, increasing concurrency only adds waiting time.
Why Is Connection Pooling (Keep-Alive) Important?
Performing a new TCP and TLS handshake for every request is expensive both in terms of latency and concurrency. Reusing the connection (keep-alive) gives much higher throughput at the same concurrency:
The size of the client pool should not exceed the concurrency the provider allows. If it does, the extra connections are established and closed immediately, and the handshake cost is wasted.
The Relationship Between Concurrency and IP Count
Increasing concurrency also increases the request density coming out of the same IP. If the target site applies a per-IP rate limit, raising concurrency over a single IP leads directly to being blocked. The right approach is to scale concurrency together with the number of IPs .
Do not exceed 1–2 concurrent connections per IP per target. If you want to send 60 concurrent requests, you need at least 30–60 different exit IPs. For pool sizing our proxy pool article .
Target-Friendly Rate Management
Just as important as concurrency is spreading requests over time. Instead of sending 40 requests at once, distributing them with small delays both looks more natural to the target and prevents queue build-up.
- Add jitter: A random wait of 150–350 ms instead of a fixed 200 ms reduces the bot signature.
- Use a token bucket: A token bucket producing N requests per second prevents sudden bursts.
- Apply back-off: When you get a 429, lower concurrency gradually and raise it slowly once success returns.
- Keep a separate queue per target: One site slowing down should not affect the others.
Typical Limits Across Different Proxy Types
| Type | Typical concurrency | Limiting factor |
|---|---|---|
| Datacenter | High — hundreds | Bandwidth and target rate limit |
| ISP | Medium-high | Target tolerance per IP |
| Residential | Medium — plan-based | Provider account quota |
| Mobile | Low | Single device and carrier connection |
Because mobile proxies exit through a single physical modem, they offer low concurrency by their very nature; in return they have the highest trust score. For details see our mobile proxy article .
Summary
Concurrency does not determine speed on its own; it does so together with latency. The way to find the right value runs through an experimental load test: find the point where throughput flattens and latency shoots up, and run at 70% of it. Fix the connection pool to that value, scale concurrency together with the number of IPs, and back off when a 429 arrives. To measure the latency of your current proxies ping test and proxy checker tools.