Concurrent Connections

What a connection is and how it works

A network connection is a communication link that two programs establish to exchange data. For example, a browser connects to a web server to request a page and receive its contents. The connection provides the path for that exchange; a request and a response are messages sent over it.

Consider a conventional TCP connection. The application contacts the server's IP address and the port for the required service. The two sides exchange control messages to establish the connection. Data then travels in small units called packets. TCP tracks delivery, arranges retransmission of lost data and presents the data to the receiver in the correct order. Both sides keep information about the exchange while the connection exists.

With a conventional TCP proxy, the application first connects to the proxy server. The proxy establishes a separate connection to the destination website and passes data between the two connections, in both directions. It therefore maintains communication with both the client and the destination.

The application can send a request, receive a response and use the established connection for another exchange. Receiving a page, for example, does not necessarily close the connection: the browser may retain it for further requests to the server. When it is no longer needed, one side closes it; an error or timeout can also end it. Until it closes, a connection can exist without continuously transferring data.

A program can maintain several such connections at once: receiving data on one, waiting for a reply on another and keeping a third ready for a later request. These are concurrent connections. The count describes the communication channels open at that moment, rather than the total number of requests made since the program started.

What the limit measures

An open connection occupies a place in the relevant allowance. Once it closes and the service removes it from the count, that place becomes available again. This is a limit on current activity, so reaching it does not use up a monthly balance of connections.

How connections count towards the customer's allowance is a separate service rule. Two network legs at the proxy do not automatically consume two units of the quota.

Providers set these limits because open connections consume server resources even when they transfer little data. A connection waiting for a reply still needs to be maintained. Controlling their number helps a service keep enough capacity for the workloads it has agreed to support.

Several different limits can apply to the same service:

Unlimited traffic therefore says nothing about the number of simultaneous connections. There can also be a separate limit on how quickly new connections are opened. Rapidly opening and closing them may reach that limit even when few remain open at any one moment.

Why thread counts do not equal connection counts

The number of threads or workers in an application describes how it organizes tasks. It does not reliably tell you how many connections the proxy will count. One task may contact several servers, and an asynchronous script can manage many network operations without creating a separate operating-system thread for each one.

Nor does every HTTP request require a new connection. A client can reuse an existing connection, and HTTP/2 can carry several requests at the same time over one connection. The request count is therefore different from the connection count.

The provider's terminology also matters. A limit described as “threads” or “sessions” may refer to open connections or to requests being processed. A sticky session, which keeps the same proxy IP for related requests, does not necessarily represent one network connection. The useful definition is what the service actually counts.

Which programs share the allowance?

A limit may belong to an account, a purchased package, an individual proxy IP or a particular gateway. For an account or package limit, add together the connections from every program and device using that allowance. Dividing an IP list between several computers does not create a separate quota for each computer.

With a per-IP limit, the distribution is different: one busy address can reach its ceiling while another has room available. Moving some work to the second address can help, provided the service does not also impose a lower shared limit. A package may have both an overall allowance and smaller allocations for individual users or client IPs.

The number of client IPs permitted to authenticate is another setting. It controls which networks can access the proxies, rather than how many connections those networks can open. Several devices behind one public IP may share both that access rule and the connection allocation attached to it.

Changing the proxy IP seen by a website does not reset an account-wide connection allowance. Likewise, switching a sticky-session name or protocol does not automatically provide more capacity. The limit remains attached to whichever account, package or endpoint the provider uses for its count.

Why connections accumulate

Connections accumulate when new ones are opened faster than existing ones are closed. This can happen while loading pages, downloading files or running other network tasks in parallel: some connections are still transferring data or waiting for a response while the application opens additional ones. These connections count towards the allowance at the same time and can together exhaust the proxy connection limit.

Slow responses keep connections occupied longer. If a program continues starting new work at the same pace, unfinished work builds up. If it instead holds parallel activity at a fixed level, a slower website generally means fewer completed tasks per minute. Both situations can occur without any change to the proxy package.

Long downloads and connections waiting for a timeout can have the same effect. A large number of open connections can therefore coexist with a low transfer speed: much of the time is being spent waiting rather than moving data.

Some connections are deliberately kept open between requests. This is usually called keep-alive. It avoids setting up a fresh connection each time, but an idle connection may still occupy a place if the service counts open connections. A connection returned to the application's pool is available for reuse; it has not necessarily been closed at the proxy.

A separate problem is faulty connection cleanup. This can occur in ready-made software as well as custom scripts. For example, code may start reading a response, encounter an error and begin another request without finishing or closing the previous response. If new connections keep opening while old ones remain occupied, the application can exhaust its allowance without doing more useful work. This is a reason to check cleanup after errors and cancellations, not just after successful requests.

Correct cleanup lets the client reuse a suitable connection or close one it no longer needs. Timeouts prevent abandoned operations from waiting indefinitely. Disabling reuse everywhere is not a general fix: it adds connection setup work and can increase the rate of new connections. The aim is a controlled number of reusable connections, with unnecessary ones released or closed properly.

Why the proxies seem to work, then stop, then work again

Intermittent failures under load are a reason to check the connection limit early. Some proxy addresses appear to work while others fail; shortly afterwards, the pattern changes. From the application's perspective, it can look as though different parts of the proxy list keep going offline.

One explanation is that the shared allowance is full. Existing connections may continue, while attempts to open more are rejected or left waiting. As earlier connections close, some new attempts get through. Other attempts fail when the available places fill again. The changing result comes from competition for the same allowance, rather than a fixed group of broken IPs.

This behaviour is sometimes described as throttling. Here, the restriction affects admission of new connections; it does not necessarily reduce the speed of every established connection. The precise response depends on the service: it may return a clear limit message, refuse a connection or leave the client to time out. A waiting queue is not guaranteed.

To check this explanation, compare failures with the connection count and temporarily lower parallel activity across the programs sharing the quota. If failures stop when activity drops below the limit and return when it fills again, the connection cap is a likely cause. Similar interruptions can also come from the target website or network. A timeout or an HTTP 429, 502 or 503 response alone does not establish that the proxy connection limit was reached; the source and wording of the error matter.

How to keep useful work within the limit

Start with the actual sites and operations your software needs to perform. Increase parallel activity gradually and observe successful results, response times and connection peaks. A brief test against a fast page may not represent a full run involving logins, large responses and slower endpoints.

1. Give all programs a shared connection budget. Leave room for other activity and short bursts. If several processes use the same package, setting each process to the package's full allowance can overload the service when they run together.
2. Control both tasks and connections. A connection pool stores connections for reuse. Check whether its size setting is a hard limit or merely the number retained afterwards; some clients open extra connections unless a waiting mode is enabled. Keep response cleanup and timeouts in place, including when a job fails.
3. Spread out launches and retries. Starting every browser at once or immediately repeating every failed request creates another peak. Use a limited number of retries with increasing delays, and keep them inside the same workload budget. A timeout also does not prove that a submitted action failed, so repeating a purchase or update needs care.
4. Measure completed work. More workers are useful only while they improve successful throughput. When they mostly add waiting and errors, a lower setting may finish the same job sooner. If a dashboard averages activity over time, brief peaks may be less visible than in the application's error timestamps.

For browser tasks, avoiding unnecessary downloads can also reduce network activity. Blocking images or video may help when the task does not need them; removing scripts can break the operation itself. Judge the change by whether the intended task still completes correctly.

When a higher limit helps

More connection capacity is useful when the application is managing its connections properly and the required workload consistently reaches the provider's ceiling. It can allow more tasks to run together without competing for the same small allowance.

The purchase must increase the limit that is actually being reached. Adding IPs can help with a per-IP restriction when work is spread across them. For a shared package limit, the new package or add-on must raise that shared allowance. An increase in IP quantity alone does not prove that it will do so.

There are other ceilings as well. The client may have a smaller pool, the computer may run short of network resources, or the destination may limit requests. A single mobile connection also has its own available bandwidth, regardless of the number of permitted proxy connections. Buying more concurrency does not remove those constraints, and it does not repair a script that keeps leaking connections.

The practical target is enough room for the workload's normal peaks while keeping failures low. Once that is established, an extra connection allowance can be a useful capacity upgrade rather than a way to postpone fixing the application.