Concurrent Sessions (Threads)
The number of simultaneous connections or requests you can run through a proxy service at the same time.
Concurrent sessions - often called threads - are the number of simultaneous connections you can have open through a proxy service at once. If your plan allows 100 concurrent sessions, you can run 100 requests in parallel; the 101st waits until one finishes. Concurrency is a primary lever on how fast you can scrape.
It directly determines throughput. Total speed is roughly concurrency multiplied by per-request speed. Doubling concurrent sessions roughly doubles how many pages you can fetch per minute, up to the point where the target's own limits or your parsing pipeline become the bottleneck. High-volume scraping needs high concurrency.
Providers price and package concurrency differently. Some bandwidth-based plans allow effectively unlimited concurrent sessions and charge only for data transferred; others cap concurrency by plan tier. Knowing whether your limit is concurrency, bandwidth, or both is essential for sizing a scraping operation.
More concurrency is not always better. Running too many parallel requests against a single target - even across rotating IPs - can trip site-wide anti-bot defenses or overwhelm the target. Balance concurrency against per-IP rate limits and polite pacing so you scale throughput without drawing attention.
Counting what runs at the same time
Concurrency is how many requests are in flight simultaneously, and it is the number that decides throughput. A job of a million pages at one request at a time takes weeks. The same job at two hundred at a time takes hours. Nothing else about the job changed.
Two different limits apply, and confusing them wastes money. The provider limit is how many connections the proxy service will accept from you. The target limit is how many the destination tolerates from a single address before it starts refusing, usually as 429 or a silent slowdown.
The target limit is per address, which is the important part. Doubling concurrency through one address doubles your rate against that address and gets you rate-limited twice as fast. Doubling the number of addresses while keeping per-address concurrency the same doubles throughput without changing what any single address looks like.
There is also a cost dimension on metered products. Concurrency does not change how many bytes you transfer, so it costs nothing extra on residential. It changes only how quickly you spend the same money.
Our limits, and the ones that will actually stop you
We do not cap concurrent connections or session count on residential. The ceiling you meet in practice belongs to the destination:
Scaling by addresses, not by threads
# Wrong: 200 threads through one session
login_c_US_s_1_ttl_15m x200 threads -> 429 from the target
# Right: 200 threads across 50 sessions
login_c_US_s_1_ttl_15m x4 threads
login_c_US_s_2_ttl_15m x4 threads
...
login_c_US_s_50_ttl_15m x4 threads
# Or drop sessions entirely for a new exit per request:
login_c_US- Rotating residential without a session id spreads requests across exits automatically, which is the simplest way to raise concurrency safely.
- On static addresses, concurrency per address is what you tune. Twenty datacenter addresses at ten threads each behaves very differently from one address at two hundred.
- Reuse connections. A pooled client keeps the tunnel to us open and removes a handshake from every request, which often matters more than raising thread counts.
- Watch for 429 rather than guessing. It is the target telling you exactly which limit you crossed.
Where concurrency planning goes wrong
Treating provider limits as the constraint
We do not cap concurrency. If you are being throttled, the destination is doing it, and more threads will make it worse.
Confusing sessions with connections
One sticky session can carry many parallel connections through the same exit. That is usually not what you want under load.
Raising threads to fix slowness
If responses are slow because the target is throttling you, more parallelism increases the queue rather than the throughput.
Assuming concurrency costs more on residential
Billing follows bytes, not connections. Concurrency changes how fast you spend, not how much.
Related terms
See this in practice
Ready to use concurrent sessions (threads)?
SotaProxy gives you access to rotating residential, mobile, datacenter, and ISP proxies. No minimum commitment.
Get started