A connection is a single network connection opened by your software through the proxy to a target site.
A thread is a unit of code execution in your software — and one thread can open many connections at the same time. Connection limits count connections, not threads.
Concurrent connections: what are they?
Concurrent connections are the number of individual network connections that can be active through your proxy service at any given time. It's not about the number of threads in your application but the total number of active network connections. The limit is aggregate across all IPs in your package — it applies to the service as a whole, not to each IP. So if your plan allows 1,500 concurrent connections, no more than 1,500 connections can be active at once across all your IPs.
The limits for each plan — and what happens when you exceed them (Slow Mode) — are set out in our Terms of Use.
Threads and their impact on connections
A thread in software development is a unit of code execution. Many applications operate in a multi-threaded environment, where multiple tasks can run concurrently. However, it's crucial to understand that one thread can open multiple connections at the same time. For example, when emulating a browser with a Chromium engine, a single thread can initiate dozens of connections to load all the elements of a webpage. This can quickly lead to reaching the limit of concurrent connections.
The issue of stuck (unclosed) connections
HTTP clients — curl, Python libraries, Java applications — usually keep connections open for reuse (keep-alive) even after a request finishes. Unless your code closes them explicitly, most languages and tools only close these idle connections automatically after 60–120 seconds. Until a connection is closed at the TCP level, it counts as active on our side — even if your script has already finished its task.
This is where the surprise usually comes from: you start a new batch of tasks while connections from the previous batch are still winding down, the two overlap, and the total exceeds your limit — even though far fewer connections are actually doing work.
How to avoid problems with connection limits
To avoid problems with concurrent connection limits, we recommend:
1. Reuse connections — and close them when done: Connection reuse (keep-alive) is a good thing — it saves TCP/TLS handshakes and speeds up scraping. The problem is only connections left open after the work is finished. Close the client or session explicitly when a task completes: in Python, use a context manager (with requests.Session() as s:) or call session.close(); in Node.js, call agent.destroy(); in Java, close your HTTP client. For simple one-off curl scripts, the --no-keepalive option forces each connection to close immediately — a blunt but reliable last resort (every request then pays a new TCP/TLS handshake, so don't use it for high-volume scraping).
2. Manage threads: Remember that a single thread can open multiple connections. Plan the number of threads based on your concurrent connection limit, not the other way around.
3. Monitor connections: Track how many connections are actually open — on Linux, ss -tan or netstat filtered by the proxy address, or your HTTP client's connection pool metrics. This shows when and why you approach the limit.
4. Tune your client timeouts: Set idle and connection timeouts in your HTTP client so unused connections close sooner, instead of waiting out the default 60–120 seconds. And if the limit itself is too low for your workload, contact support to increase it.
Purchasing additional connections
You can increase the number of concurrent connections for any service. One additional connection costs $0.03 per month, with a minimum of 1,000 connections.
For example:
A service with 500 IPs includes 1,500 concurrent connections ($69/month).
You can buy an additional 1,000 concurrent connections for $30/month.
In total, this service would then have 2,500 concurrent connections.
To increase your limit, contact support through the ticket system.
