Proxies for High Concurrent Connections

How proxy providers really sell high concurrency, why "unlimited threads" is often a fair-use policy in disguise, and what our tiers do under load.

Proxies supporting high concurrent connections are sold in more ways than any other kind, and the differences are not in the headline. Concurrency is the number of connections you hold open at the same moment. Bandwidth is bytes and everyone counts them the same way; concurrency is a policy, and policies differ, which is why two plans advertising the same thing behave nothing alike at 2,000 threads.

Here is what our tiers do under load, and how to read anyone else's answer to the same question.

The four ways proxy providers sell high concurrency

No stated limit, enforced by nothing. The common case. There is no per-account throttle in the request path, and the ceiling you actually hit is your own client, the target's tolerance, or a safety brake that exists to stop one machine exhausting a node. This is what our per-proxy and per-gigabyte tiers do: no thread cap, behind a per-source-IP brake set at 10,000 connections that no ordinary workload approaches.

A stated limit that is the price. You buy a number of connections and that number is the ceiling. Rotating Unmetered works this way: concurrency is the thing being sold, so the rung you pick is enforced, and in exchange the byte meter disappears entirely.

Unlimited, until a data threshold. The one worth reading the fine print for. A plan advertises unlimited sessions, then a fair-use clause reduces your allowance once monthly transfer crosses some figure. Your effective concurrency for the back half of the billing cycle can be a fraction of the front half, and nothing in the headline says so. This is not dishonest when it is documented; it is a problem when you sized your job on the headline.

Per-port or per-endpoint caps. Older designs allocate threads against ports rather than accounts, so your concurrency is a function of how many endpoints you bought rather than what your workload needs. Providers have been retiring this model, but it survives in enough places that it is worth confirming before you size an order around a thread count.

The question to ask any provider, ours included, is not "is it unlimited". It is: what enforces it, and what changes it mid-month.

What ours do

Dedicated datacenter, shared datacenter, residential, and rotating Premium and Shared carry no per-account thread cap. The only ceiling in the path is the per-source-IP brake, at 10,000 connections from a single client address, which is a safety mechanism against one machine saturating a node rather than a commercial limit.

Rotating Unmetered is the exception, deliberately. It is priced by concurrent connections, so the rung you buy is a real ceiling the gateway enforces. That is the trade: you stop paying by the gigabyte and start sizing by the burst. It suits a job whose bytes-per-request are high and whose concurrency is predictable, and it is the wrong shape for a spiky workload, because you are sized by the peak rather than the average.

The free tier carries a stated 10-thread figure. It exists to let you test a configuration, not to run a crawl.

One correction, because it is the most common misreading of our own pricing: shared datacenter proxies are not unmetered. They bill per proxy like the dedicated tier, but carry an allowance of 3 GB per proxy, pooled across the order so a busy address is covered by a quiet one. Only the dedicated tier has no bandwidth meter at all. Unmetered rotating versus per-GB works through which billing shape suits a data-heavy job.

Concurrency is not the same as throughput

A plan that permits 5,000 connections does not deliver 5,000 useful responses per unit time. Four things sit between the two.

Network capacity. Threads are free to promise and expensive to serve. Every open connection wants bandwidth, and a provider whose backbone is thin will queue you regardless of what the plan allows. Ours runs on 100+ Gbps of network capacity.

Pool size against target tolerance. Concurrency spread thinly across many addresses looks different to a target than the same concurrency concentrated on a few. If your bottleneck is a per-IP rate limit rather than your own throughput, more threads through the same exits buys you nothing, and working out how many proxies a workload needs is the calculation that matters instead.

Your own client. Most high-concurrency disappointments are local. Default connection-pool sizes in HTTP libraries are small, DNS resolution serializes, and an event loop blocked on parsing will not open sockets no matter what the proxy permits. Measure your client alone against a local endpoint before blaming the proxy.

Failure handling. At 2,000 threads a 2% failure rate is 40 simultaneous retries, and a retry storm that fires them all at once looks exactly like an attack to the target. Concurrency without backoff converts a small problem into a block.

What actually breaks first at high connection counts

In rough order of how often it is the real cause:

File descriptors on your own machine. A thousand sockets need a thousand descriptors plus overhead, and default limits on a developer laptop are lower than that. This is the single most common cause of a high-concurrency job stalling at a suspiciously round number.

Ephemeral port exhaustion. Each outbound connection consumes a local port, and sockets in TIME_WAIT hold theirs for a while after closing. A job cycling connections fast can run out of ports without ever reaching its thread target.

Connection churn rather than reuse. Opening and tearing down a TCP connection per request is expensive at volume. Keep-alive and a properly sized connection pool cut that overhead substantially, and HTTP/2 multiplexing reduces socket count further where the target supports it. This is a client-side fix that costs nothing.

The target, not the proxy. Rate limits, connection caps per source, and challenge pages all arrive as failures that look like proxy problems. Reading a proxy error code before blaming the pool covers telling those apart, and it is worth doing before you buy more threads.

Protocols, and one limit to know before you plan around it

Both HTTP(S) and SOCKS5 are available on every paid product, on the same credential. Concurrency behaves identically on both, and a session pinned on one holds on the other because the listeners share a session store.

Where it matters for planning: our SOCKS5 implements CONNECT only. BIND and UDP ASSOCIATE are refused with the protocol's own "command not supported" reply, so there is no UDP through these proxies at all. If your high-concurrency workload is datagram-based, this is the wrong infrastructure and you should know that now rather than after sizing a plan around it. Anything TCP is fine, which covers scraping, automation, API access and account work. The full protocol comparison goes through what each one buys.

Sizing a plan honestly

Concurrency is the one number people habitually over-buy, because it is the one that sounds like capability.

Measure your peak, not your total. A job averaging 200 connections but spiking to 1,200 for ten minutes is a 1,200-connection job. On a metered tier that spike costs nothing extra; on a connection-priced tier it is the whole bill.

Separate "can I open it" from "should I". Most targets degrade well before your plan does. The useful ceiling is usually the target's, and finding it takes an afternoon of measurement rather than a larger plan.

Check what changes mid-month. With any provider, ask whether the concurrency you bought is the concurrency you have in week four. With ours, it is: the per-GB tiers have no thread cap to reduce, and Rotating Unmetered's rung is fixed for the cycle.

Test at small scale against the real target. Run a bounded slice, count successes rather than requests, and read consumption off the dashboard. What the usage numbers do and do not measure covers interpreting that honestly.

Choosing a tier for a concurrent workload

Dedicated datacenter for sustained high concurrency against targets that accept hosting ranges. No thread cap, no byte meter, and the per-request cost falls as you push more through the same addresses.

Rotating Premium or Shared when the constraint is per-IP rate limiting rather than raw throughput. You are buying address breadth, and concurrency stays uncapped while bytes are metered.

Rotating Unmetered when bytes-per-request are high and concurrency is predictable. The byte meter goes away and you size threads instead.

Residential when the target refuses hosting ranges outright. Concurrency is uncapped and traffic is metered, so the cost driver is payload rather than threads. Coverage runs to 170+ countries.

Shared datacenter for lighter concurrent work where the pooled 3 GB per proxy is comfortable.

Choosing the right proxy type for a target covers the half of this decision that is about the target rather than the thread count, and current rates for every tier are on the pricing page.

What we do not sell

No mobile proxies, no ISP proxies, and no scraping API. If your high-concurrency plan depends on any of those, part of your stack belongs with another provider, and it is cheaper to know that before you buy than after.

We also publish 99.9% uptime as a target, not a service level we contract to, with automated health checks running every five minutes. A number on a marketing page is not a commitment, ours included, and the useful question to put to any provider is what happens to your open connections when a node fails rather than what the percentage says.