---
title: "Concurrency"
url: https://proxy.wiki/glossary/concurrency/
type: Glossary Term
author: "proxy.wiki editorial"
published: 2026-08-19
updated: 2026-08-29
site: proxy.wiki
topics: ["Web scraping"]
license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/
---

# 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](/glossary/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](/glossary/rate-limiting/) responses, often with Retry-After |
| The target’s bot defence | [Challenges](/glossary/captcha/) 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](/glossary/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.

## Frequently asked questions

### How many concurrent requests should I use?

The highest number at which your measured success rate has not started to fall. Raise it in steps and watch quality rather than speed, because throughput keeps rising for a while after the results begin to degrade.

### Why did raising concurrency make the job slower?

Because the extra parallelism produced retries. Blocked and challenged requests cost time and often bandwidth, and past a certain point each additional worker adds more failures than results.

### Is the limit set by my provider or by the target?

Both, independently. Your plan caps concurrent connections at the gateway, and the target enforces its own limits per address, per session or per account. Exceeding either produces failures, but the symptoms differ.

## Sources

1. [RFC 6585: status code 429, the usual response to excessive parallelism](https://www.rfc-editor.org/rfc/rfc6585.html)