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.

Concurrency is the number of connections you hold open at the same moment, and unlike bandwidth it is a policy, so two plans advertising the same thing can behave nothing alike at 2,000 threads. On Node4, every paid product except one has no per-account thread cap; Rotating Unmetered is the exception, because concurrent connections are the unit it sells. With any provider, the question that settles it is what enforces the limit and what changes it mid-month.

Below: the four ways concurrency is sold, what Node4's tiers do under load, and what breaks first when you push the number up.

The four ways proxy providers sell high concurrency

No stated limit, enforced by nothing. 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 very high per-source-address brake that ordinary workloads do not approach.

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 there is no byte meter (network safety limits still apply).

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. Unmetered proxy plans compared lays out what each provider's unmetered plan actually caps.

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 Datacenter carry no per-account thread cap. The only ceiling in the path is the per-source-address brake, a very high connection cap per 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 distinction to keep: shared datacenter proxies are not unmetered. They bill per proxy like the dedicated tier, but carry a bandwidth allowance 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 the order worth checking:

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. It is a 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. Of the three commands RFC 1928 defines, 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

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

Measure your peak, not your total. For example, 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.

Count connections the way the gateway does. An HTTPS tunnel or a SOCKS5 connection holds one slot for its whole life, including idle time in your client's keep-alive pool. A plain-HTTP request holds a slot only while it runs. A client that keeps hundreds of idle HTTPS tunnels open is using hundreds of slots, so cap the pool at the concurrency you bought.

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 it.

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 Datacenter 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. There is no byte meter and you size connections 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. Current country coverage is listed on the residential page.

Shared datacenter for lighter concurrent work that fits inside the pooled per-proxy allowance.

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 each product name above links to its current rates.

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.