Every time a new connection lands on a rotating Nodetonet proxy, the router has to decide which device in the pool will handle it. The decision happens in milliseconds and is invisible to the client — but if you are tuning a pool or debugging why one phone seems overloaded while another sits idle, knowing what the algorithm actually does is essential.
TL;DR: Nodetonet uses a two-rule cascade — least-connections first, then round-robin to break ties — applied only to devices that pass a strict eligibility check. Sticky sessions short-circuit the picker entirely for returning clients.
Why a two-rule picker instead of pure random?
Pure random selection is simple but produces uneven load over short time windows, especially with heterogeneous pools where one device has a faster uplink or lower latency than another. A naive round-robin distributes evenly on paper, but it ignores in-flight load — sending request number three to a device that is already juggling twenty connections.
The combined least-connections + round-robin approach solves both: least-connections tracks real load, and round-robin provides a clean, fair tiebreaker when multiple devices happen to share the lowest count. This is the same principle used in production HTTP load balancers and works equally well whether your pool has two phones or two hundred.
Rule 1 — least-connections wins
When a connection arrives at a backconnect endpoint bound to a token group, the router queries each eligible device for its current in-flight connection count. The device with the lowest count wins the next connection.
This matters more than it looks. Consider a pool of three phones where phone A is on a fast LTE connection processing ten concurrent scraping threads, and phones B and C are nearly idle. Least-connections will naturally send the next burst to B and C, keeping A from saturating and degrading the pool for everyone. It absorbs bursty workloads and heterogeneous hardware without any manual weight configuration.
Rule 2 — round-robin breaks ties
What if several devices are tied at the same count? Pure least-connections with no tiebreaker would always pick the first eligible device, starving the others. Nodetonet avoids this by keeping a per-group cursor that advances every time a tie must be broken:
pool = [phone-A, phone-B, phone-C] # all idle, 0 connections
cursor = 0
request 1 -> phone-A (cursor advances to 1)
request 2 -> phone-B (cursor advances to 2)
request 3 -> phone-C (cursor advances to 0)
request 4 -> phone-A (cursor advances to 1)
...Under light load — for example, when you first bring a pool online — traffic fans out evenly. Under heavy load, least-connections takes over and the cursor only matters at the margins. The two rules complement each other perfectly.
How the two rules compare at a glance
| Scenario | Primary rule triggered | Effect |
|---|---|---|
| All devices idle (0 connections) | Round-robin tiebreaker | Even distribution across the pool |
| Devices at different load levels | Least-connections | Underloaded devices absorb new traffic |
| Some devices tied at same count | Round-robin tiebreaker on the tied subset | No starvation within the tied group |
| Sticky session present | Session map lookup (bypasses picker) | Returns directly to bound device |
| All devices ineligible | No selection possible | Connection refused with a clear error |
Eligibility — what qualifies a device
The picker only considers devices that pass an eligibility check first. A device is silently excluded from selection if any of the following is true:
- Offline. The persistent WebSocket control channel from the Android agent has timed out. There is no working uplink, so the router will not route to it. See device health — what online actually means for the signals involved.
- In ERROR state. The agent reported a hard failure: the radio is off, a captive portal is blocking data, or no data signal is available. The device re-enters eligibility automatically once it recovers — no manual action needed.
- IP rotation in flight. When a sticky session TTL expires, Nodetonet instructs the device to drop and re-establish its mobile data link to get a fresh IP. This process takes roughly five to fifteen seconds. During that window the device is excluded from the pool so no new traffic is routed into a half-broken radio state. Read more about how IP rotation is triggered in token rotation — when and why.
If every device in the group fails the eligibility check simultaneously, the incoming connection is refused immediately at the proxy listener with a descriptive error — it is never silently queued. This fail-fast behaviour is intentional: a stalled connection that never resolves is harder to debug than a clear refusal.
If you are seeing frequent eligibility failures, check the per-device traffic charts on your rotating proxy dashboard and cross-reference with the proxy checker to confirm which devices are genuinely online.
Sticky sessions — when the picker is bypassed entirely
The least-connections + round-robin picker only runs for connections that carry no session identifier. As soon as the proxy username contains a -session-XXXX suffix, the router performs a fast map lookup instead:
- Binding found and within TTL: the connection is routed directly to the bound device, regardless of how many connections it currently holds. The picker is never consulted.
- Binding expired or not yet created: the picker runs normally to select a device, and the result is stored as a new binding for that session ID.
This design keeps sticky sessions lightweight. The hot path is a single in-memory map lookup; the picker is only involved on the very first request of each session. For a detailed walkthrough of session mechanics, see sticky sessions explained.
The tradeoff is that a pinned device can accumulate more connections than its peers for the duration of the session. If you use very long TTLs with many concurrent sessions, monitor the per-device spread to make sure the pool does not tip out of balance. Token groups with automatic failover will re-pin a session to a different device if the original goes offline mid-session.
Reading pool behaviour from your traffic charts
Open any rotating proxy bound to a token group and check the per-device traffic split. Here is how to interpret what you see:
- Even spread across all online devices: the pool is healthy and the picker is distributing as expected.
- One device at high percentage, others near zero: the low-traffic devices are repeatedly failing the eligibility check. The picker keeps falling back to the one survivor. Check battery, signal and agent version on the idle phones.
- Traffic concentrated on one device but others are online: you may have a large number of long-lived sticky sessions all bound to the same device from an earlier period. Let the TTLs expire or rotate the session IDs.
For deeper investigation, the proxy checker tool lets you test a specific endpoint and see which device IP is returned, so you can confirm the picker is selecting the devices you expect. If you need to verify carrier or geo targeting on top of load balancing, see geo-targeting for username modifier syntax.
Upstream forwarding and the picker
If your token group is configured with upstream residential forwarding, the picker still selects a device first — the selected device's outbound connection then chains to the upstream provider. The eligibility rules and the two-rule cascade apply identically; the upstream layer is transparent to the selection algorithm.
Building the right pool for your workload
The algorithm works best when the pool has devices with similar uplink quality and connection budgets. Mixing a phone on weak 3G with several phones on solid 5G will cause the 3G device to accumulate connections more slowly, which can temporarily make it look "cheapest" to least-connections during bursts. You can isolate low-quality devices into a separate token group and route only lower-priority traffic there.
For guidance on pool sizing, failover configuration, and creating token groups from scratch, see token groups — creating pools and set up a rotating mobile proxy from scratch. If you are managing a large fleet, bulk operations for 100+ proxies covers how to configure and monitor at scale.
Least-connections does the work. Round-robin makes it fair. Eligibility keeps you out of trouble.
Get started
Ready to build your own rotating pool? See how mobile proxies work on Nodetonet, or create a free account and set up your first token group in minutes. Questions? Reach us at support@nodetonet.com or join the community on Discord.