Count proxy connections across the account, not just workers

A proxy limit of twelve concurrent connections can be exhausted by three small clients. No single client needs twelve workers to reach it.

Consider this illustrative snapshot:

All twelve slots are occupied. In a product that rejects new connections at this limit, the next connection fails while existing connections remain active. These are example counts, not a measurement of a provider or a universal rule for how overload is handled.

Find the scope of the limit

Before changing code, establish whether the allowance applies to the account, product, credential set, IP or another resource. Two applications can share a limit even when they run on different machines. Giving each application its own local cap does not keep their combined total below the account cap.

Confirm what is counted, too. A request, a worker and an open connection are different units. A browser can open several connections while loading a page. A client can retain an idle connection for reuse. Protocol multiplexing can carry more than one request on a connection. The mapping depends on the client, protocol and service.

Measure before raising the worker count

Record active and idle connections, request duration, attempts and successful results. Check whether another process uses the same allowance. A rise in retries can add work precisely when the system has little spare capacity.

Average in-flight requests can be estimated as request rate multiplied by average request duration in a stable workload. For example, five requests per second taking two seconds on average imply about ten requests in flight. That estimate becomes a connection estimate only if the workload really uses one counted connection for each in-flight request. It also says little about short bursts.

Keep the combined load bounded

Use a shared concurrency budget across the clients that consume the same quota, or allocate explicit portions of that budget to them. Leave headroom for browser traffic and operational checks. Release unused connections according to the client's documented behaviour.

If the service reports overload, use bounded retries with backoff and a stop condition. Unbounded retries can keep the account saturated. Distinguish a provider connection limit from a target website's rate limit before choosing a response.

A higher allowance can be appropriate once measurement shows that useful work needs it. Increasing workers alone does not show that the bottleneck has moved.

Source: ProxyData: Limited Concurrent Connections. This adaptation was prepared with AI assistance.