How many concurrent connections can I run

Concurrency is the number of requests in flight at the same time, and it is the setting that most often decides whether a job runs smoothly or collapses into timeouts.

What your plan allows

Concurrency scales with your package rather than being a single fixed number. Your current allowance is shown in the Dashboard alongside your proxy list. If you need more than your plan supports, request a custom package — headroom is cheaper than a failed run.

Sizing your threads

Start lower than you think. A good starting point is 10–20 concurrent requests per proxy for datacenter, and fewer for residential where each request travels further.

Then increase in steps and watch two numbers:

• Success rate. If it falls as you add threads, the target is rate limiting you, not the proxy.
• Average response time. If it climbs steeply, you have saturated something and are queueing.

Stop at the last setting where both were healthy.

What happens if you exceed the limit

Additional connections are refused or queued rather than served. In your client this usually surfaces as a connection reset or a timeout — see Proxy timeout / fail.

Reduce the need for concurrency

Reuse connections with keep-alive, skip assets you do not need, and cache anything you fetch more than once. Most scrapers can halve their thread count without losing throughput.