A mobile phone is not a datacentre. A single Android handset on a cellular network can comfortably hold a few dozen long-lived TCP connections; push past that and the radio stack starts dropping packets, battery drains faster, and your customers start blaming you. The solution is a hard ceiling on per-client concurrency — and the Threads field on every Proxy Client is exactly that ceiling.
This guide explains what the cap counts, what the refused connection sees, how to size the number correctly across device types, how threads interact with quota and expiry controls, and how to read live usage from the panel. If you are new to the overall access-control model, start with per-customer proxy clients first.
What exactly does the Threads cap count?
Open any proxy from the panel, scroll to the Proxy Clients section, and create or edit a client. The field is labelled Threads. Leave it empty for unlimited; enter a positive integer to impose a ceiling.
The cap counts currently-open tunnels for that client — not requests per second, not bytes transferred, not the number of domains visited. A client with threads = 20 can keep twenty parallel scraper workers running indefinitely. The twenty-first worker that tries to open a tunnel before any of the existing twenty close is refused immediately.
This is the "noisy neighbour" insurance alongside quota limits and time-limited expiry. Quota stops one customer eating your bandwidth bill. Threads stop one customer monopolising your hardware. The two limits solve different problems and can be combined on the same client.
What the refused connection sees
When a client is at its thread ceiling, the response depends on the protocol:
- HTTP/HTTPS — the proxy auth layer returns a real
429 Too Many Connectionsbefore anyCONNECTor tunnel setup begins. The client never touches the target server. - SOCKS5 — the connection is refused at the greeting stage, also before any traffic reaches the target.
Three things are always true for a refused connection:
- Immediate — no queue, no wait, no slow timeout. The caller gets an answer in single-digit milliseconds and can back off or retry another session.
- Deterministic — same client credentials, same proxy, same instant: same answer every time. There is no shared pool that "sometimes lets you in".
- Does not consume quota — refused connections are not counted against any byte cap. Your customer does not lose allowance for a connection that never forwarded data.
If your customers are using rotating sticky sessions (the -session-XXXX username suffix), each session counts as a separate tunnel for thread-counting purposes. A client running five sticky sessions and five plain connections is using ten threads total.
Sizing the cap: a practical guide
There is no universal magic number — the right cap depends on the device behind the proxy, the carrier, and how intensively your customer plans to use the connection. The table below gives starting-point ranges:
| Device type | Suggested threads | Reasoning |
|---|---|---|
| Mid-range Android phone, CGNAT carrier | 10 – 20 | Comfortable headroom; modern handsets handle this without radio stress |
| Flagship phone (Turkcell, Vodafone, Türk Telekom) | 30 – 50 | Larger kernel buffer, faster radio — both stay happy at this load |
| PC agent on a wired connection | 100 + | No mobile-radio constraint; OS socket limits are the ceiling instead |
| Upstream-only proxy (no device) | Match upstream plan | The cap protects your upstream allowance, not a phone |
| Shared device (multiple clients) | Sum must not exceed device capacity | Each client's cap stacks; the first customer to ramp up will degrade the rest |
If multiple paying customers share the same physical device, allocate threads deliberately. The sum of all client caps on that device should not exceed what the device can reliably sustain. The panel shows live open-connection counts per client so you can verify the headroom in real time.
How threads interact with other per-client controls
Threads are one of four independent limits you can set on a Proxy Client. They are AND-ed together — every limit must be satisfied for a new connection to open:
- Threads — maximum simultaneous open tunnels (this guide).
- Quota — maximum bytes transferred. See quota limits per client.
- Expiry — the client stops working after a set date. See time-limited proxy clients.
- IP and domain restrictions — allow or deny access by source IP or destination domain. See IP allow/deny lists and domain restrictions.
A client with threads = 5, quota = 10 GB and an expiry date hits whichever limit fires first. They are not alternatives — a new connection must clear all four hurdles simultaneously.
This design means you can create granular reseller tiers without any custom logic in your own code. A trial client might have 5 threads, 2 GB quota and a 7-day expiry; a premium client might have 50 threads, unlimited quota and no expiry. The panel enforces all of them for you. For the full reseller pattern see per-customer proxy clients.
Reading live thread usage from the panel
Each Proxy Client row shows live open connections alongside the thread cap. The counter updates in real time — it ticks up the instant a new tunnel opens and down on TCP close. You do not need to poll an API or check logs; the panel surface is the fastest view.
If you want to confirm a client is at its ceiling, watch the live counter. If it is consistently sitting at the cap, the client may be throttled more than intended — raise the cap, create an additional client for that customer, or ask them to reduce parallelism.
For deeper audit trails — who connected, when, and from which IP — see audit logs. The thread cap is about real-time enforcement; the audit log is about historical accountability.
Common mistakes to avoid
- Setting the cap too low for the use case. A scraper that opens 30 parallel browser tabs will see constant 429s against a
threads = 5client. Match the cap to the customer's actual workload. - Ignoring the shared-device sum. Ten clients each capped at 30 threads all on the same phone means up to 300 concurrent tunnels, which will overwhelm any handset. Audit the sum before publishing credentials.
- Confusing threads with bandwidth. Threads count open tunnels; a single tunnel can push many megabits. High-throughput downloads do not need many threads — they need bandwidth. Use the quota limit for bandwidth control.
- Not pairing threads with expiry for trial accounts. A trial client with no expiry but a thread limit can sit open indefinitely and accumulate charges. Combine threads with a short expiry for time-boxed trials.
What to do next
Thread limits are one building block of a full multi-tenant proxy business. Once you have them configured, explore:
- Quota limits per client — the bandwidth-budget complement to thread limits.
- Time-limited Proxy Clients — set an expiry so trials terminate automatically.
- Per-customer proxy clients — the complete design pattern for reselling proxy access.
- Rotating proxies on Nodetonet — token groups, round-robin selection and failover.
- Create a free account and configure your first client limits in minutes.