Concurrency
How many proxy connections you may run at once — often the real constraint on throughput, not bandwidth.
Concurrency is the number of simultaneous connections a plan permits. It is frequently the limit you hit first, and frequently the one buyers overlook while comparing price per gigabyte.
#Why it matters more than it appears
Throughput is roughly concurrency divided by average response time. Doubling concurrency and halving latency have the same effect on how much work you complete. A cheap plan capped at a low concurrency can be slower in practice than a more expensive one with a high cap, at identical bandwidth cost.
#How limits are enforced
Behaviour when you exceed the cap varies and is worth testing deliberately: some providers queue the excess, some refuse the connection, and some return an error that looks like a target-side failure. Knowing which happens saves hours of misdirected debugging later.
#Set your own ceiling too
Even where a provider permits high concurrency, hammering one destination from many addresses at once is itself a detectable pattern and a good way to attract rate limiting. The provider’s limit is a maximum, not a target.
#Why it is the setting that causes most blocks
Concurrency multiplies everything else. A request rate that is unremarkable in sequence becomes a burst in parallel, and bursts are what limits are built to catch. Raising concurrency to make a job finish sooner often makes it finish slower, because the retries and blocks cost more than the parallelism saved.
| Where the limit lives | Symptom when you exceed it |
|---|---|
| Your provider’s plan | Connections refused or queued at the gateway |
| The target’s rate limiter | 429 responses, often with Retry-After |
| The target’s bot defence | Challenges or 403, with no explanation |
| Your own machine | Timeouts, exhausted sockets, memory pressure |
The last row is worth checking first when a job degrades, because it is free to rule out and it produces symptoms that look exactly like remote blocking.
#Finding the right ceiling
Raise it gradually and watch the measured success rate, not the throughput. The correct setting is the highest one at which the success rate has not started to fall. Beyond that point extra parallelism produces retries rather than results.
Set the ceiling explicitly in your own code as well. Relying on the provider to enforce it means discovering the limit through failures instead of choosing it.