Sticky sessions explained — pin one device per session inside a rotating pool

Rotation gives you a fresh IP on every connection — perfect for broad scraping, price monitoring and any workload where each request is independent. But plenty of real tasks are stateful: a login flow, a multi-step checkout, a form that tracks your session across several pages. Rotating the IP mid-flow looks like account takeover to most anti-fraud systems, and they block you instantly. Sticky sessions solve this by pinning one session identifier to one physical device for a defined window of time, then automatically refreshing the IP at expiry — so you keep rotating identity over time without breaking any single user journey.

TL;DR: append -session-XXXX to your proxy username and every connection with that ID lands on the same device for the duration of the TTL. No code changes to the endpoint, no extra infrastructure — it is a one-field username modifier.

This guide covers the complete picture: how sticky sessions work under the hood, the exact username syntax, TTL mechanics, how to combine sticky with geo-targeting, what happens when a device goes offline, and a side-by-side comparison of sticky versus rotation for common use cases.

What is a sticky session?

In proxy terminology, a sticky session is a routing guarantee: all proxy connections that carry the same session key are forwarded through the same exit device for a fixed time-to-live (TTL). The concept is borrowed from load-balancer design, where "session affinity" or "sticky routing" keeps one user's HTTP requests on the same backend server so server-side session data stays valid.

On a mobile proxy platform like Nodetonet, the device is a real Android phone on a live carrier SIM. Each device has its own real carrier IP from the carrier-grade NAT (CGNAT) pool. A sticky session does not freeze that IP permanently — instead it pins your requests to that device, and when the TTL expires the device gets a fresh carrier IP while staying bound to your session. The result is: same trusted device, periodically refreshed IP, continuous session.

The username syntax

There is nothing to configure beyond your proxy username. Any connection whose username matches the pattern <base>-session-<id> is treated as a sticky session automatically. The router hashes the session ID, selects an eligible device from your token group pool, and pins that binding for the TTL window.

Format:  <token>-session-<any-string>
Example: u8x2-session-user42
Example: u8x2-session-a3f9c1d8-4b27-4e6e-a1cc-f2bc1234abcd

The session ID after -session- is entirely arbitrary. Common patterns:

• A UUID generated when a user logs in to your service.
• A SHA-256 hash of a browser cookie or fingerprint.
• Your internal customer ID or order ID.
• A short label like alice or bot-worker-7 for debugging.

What matters is that the same string is reused for every request in a given session. Generate it once per user journey and pass it through.

Combining sticky with geo-targeting

Sticky modifiers compose with geo-targeting modifiers in the same username field. The router first filters the pool to devices matching your geo constraints, then applies the sticky pin within that filtered set:

# Sticky to a Turkcell device in Istanbul
u8x2-country-tr-carrier-turkcell-session-user42

# Sticky to any Turkish device
u8x2-country-tr-session-order99

See Turkey proxy locations, Turkcell, Vodafone and Türk Telekom pages for available carrier tags.

Live example: rotation vs sticky

# Pure rotation — each request may exit from a different device
curl -x http://u8x2:p7q1@sub42.nodetonet.com:48888 https://api.ipify.org
curl -x http://u8x2:p7q1@sub42.nodetonet.com:48888 https://api.ipify.org
# Result: two different IPs (pool rotates)

# Sticky — same device for both requests
curl -x http://u8x2-session-abc:p7q1@sub42.nodetonet.com:48888 https://api.ipify.org
curl -x http://u8x2-session-abc:p7q1@sub42.nodetonet.com:48888 https://api.ipify.org
# Result: same IP, same device

# Two independent sticky sessions from the same pool
curl -x http://u8x2-session-alice:p7q1@sub42.nodetonet.com:48888 https://api.ipify.org
curl -x http://u8x2-session-bob:p7q1@sub42.nodetonet.com:48888 https://api.ipify.org
# Result: likely two different devices, each stable to its own session

Both HTTP and SOCKS5 connections honour the same sticky logic — the session modifier works identically regardless of which protocol you use.

TTL mechanics — the default 600-second window

A sticky binding lasts for a configurable time-to-live. The default is 600 seconds (10 minutes). This is set at the token group level, not per-session and not per-proxy — every proxy that draws from the same group shares its TTL setting.

Valid TTL values run from 60 seconds to 3,600 seconds. Choose based on how long a typical user journey in your use case lasts:

You change the TTL on the token group settings page in the Nodetonet panel. No endpoint changes, no code redeploy — the new value takes effect for sessions opened after the save.

What happens at TTL expiry — the exact sequence

This is the part most people get wrong, so it deserves precise explanation. When the TTL window closes for a sticky session:

1. The router sends an IP-rotation command to the bound device. The device briefly drops its mobile data connection and reconnects, which causes the carrier to issue a fresh IP from its CGNAT pool.
2. The sticky binding stays on the same physical device — it does not reassign to a different phone. The device just now carries a new exit IP.
3. In-flight HTTP/SOCKS5 connections are not killed mid-request. Any request already through the proxy at TTL expiry completes normally; only new connections after the rotation see the new IP.
4. The TTL timer resets for another full window. As long as you keep sending connections with the same session ID, the device remains your anchor.

"Sticky on Nodetonet" means same device, periodically refreshed carrier IP — not "the same IP frozen forever". If you need an IP that never changes, use a dedicated single-device proxy with IP rotation turned off entirely.

What happens if the pinned device goes offline?

Device connectivity is real-world — phones can lose signal or reboot. If the pinned device disconnects, the router does not silently drop your requests. Instead, it re-selects the next best available device in the pool and rebinds your session to it. The new device has its own IP; the switch is transparent from your proxy client's perspective, and the TTL timer continues from where it left off.

If you need guaranteed failover behaviour with device-level redundancy, read automatic failover for mobile proxies, which covers how token-group pools handle device drops.

Rotation vs sticky — choosing the right mode

Neither mode is universally better; the right choice depends on your workload's statefulness:

Most production workflows mix both modes: rotate during discovery and broad crawling, then switch to sticky for the authenticated steps. Because the mode is encoded in the username — not the endpoint — you can switch on a per-request basis without changing any connection settings.

Per-client controls and sticky sessions

Sticky sessions live inside a token group and interact with all the per-client controls Nodetonet offers. A few things worth knowing:

• Thread limits apply per client, not per session. If you have 10 concurrent sessions each making parallel requests, thread limits govern the total throughput cap. See thread limits per client.
• Quota and expiry are enforced regardless of session mode. Sticky sessions consume from the same quota bucket as rotating ones. See quota limits per client.
• IP allow/deny lists apply to the connections entering the proxy, not the exit IPs. Sticky does not bypass those controls.
• Domain allow/deny lists apply per-request as usual.

Sticky with an upstream provider

If your token group chains to an upstream residential provider, the sticky binding attaches to whichever upstream credential was selected at session start. That upstream credential is then reused for the full TTL, giving you consistent exit identity through the chain. This is useful when you need the trust of a residential IP but want multi-session stickiness managed at the Nodetonet layer. Read sticky upstream sessions for the configuration details.

TCP/IP fingerprint and sticky sessions

Nodetonet supports TCP/IP fingerprint spoofing to make connections look like real Android devices at the network layer. When combined with sticky sessions you get a double layer of consistency: the same device (same carrier IP range, same CGNAT envelope) and the same network fingerprint across every request in a session. Anti-bot systems that inspect TLS JA3/JA4 fingerprints alongside IP reputation see a coherent mobile identity throughout the session window.

Diagnostic: verifying your sticky session is working

The quickest sanity check is to make two requests with the same session ID and compare the exit IP:

# Run twice with the same session suffix
curl -s -x http://u8x2-session-test99:p7q1@sub42.nodetonet.com:48888 https://api.ipify.org
curl -s -x http://u8x2-session-test99:p7q1@sub42.nodetonet.com:48888 https://api.ipify.org
# Both should return the same IP

You can also use our free What is my IP tool in a browser configured to use the sticky-session proxy — the reported IP should remain stable across page reloads within the TTL window. For deeper inspection, the proxy checker reports the exit IP, ASN, and carrier in one call.

Get started

Sticky sessions require no extra signup — they are available to every Nodetonet account as soon as you create a token group with at least one online device. Create a free account to get started, explore the full feature set on the features overview, or read token groups: creating pools to set up the underlying device pool before enabling stickiness.