How Sticky Sessions Actually Work

A sticky session is an instruction to the proxy gateway to route all requests carrying a specific session identifier through the same exit IP for a defined window. It is not a feature of the IP itself. The gateway implements it. The exit node has no awareness of it. The target has no awareness of it.

When a sticky session breaks, the failure surfaces in the application layer — a login redirect, a broken pagination sequence, an empty cart — not in the proxy connection. The proxy connection succeeded. The session consistency it was maintaining did not.

A sticky session is implemented through a session identifier embedded in the proxy authentication credentials. The gateway reads this identifier on each inbound connection and routes the request through the same exit IP assigned to that session ID when the session was first established. All subsequent requests carrying the same identifier follow the same path — regardless of which client machine or thread is sending them.

Session duration is configured either by the session ID itself — providers that accept a TTL parameter in the credential string — or by the provider's platform default. Duration limits are set at two levels: the provider's maximum allowed session length, and the physical constraint imposed by the exit infrastructure. On residential pools, the physical constraint is device availability: if the enrolled device goes offline, the gateway has no path through the pinned IP and the session breaks regardless of the configured duration.

On datacenter and ISP proxy pools, the physical constraint is absent — the exit infrastructure is provider-controlled and consistently available. Session duration is limited only by provider configuration, not by exit node behavior. This is the stability difference that makes datacenter sticky sessions more reliable than residential sticky sessions for workflows where session continuity is a hard requirement.

The session identifier is passed in the proxy username credential — typically in the format `user-session-{id}` where `{id}` is any consistent string the client chooses. Using the same string across all requests in a workflow routes all of them through the same exit IP. Using a different string starts a new session with a new IP assignment. Most providers also support appending a country or city parameter in the same credential string: `user-country-us-session-{id}` routes through a US IP and pins it for the session.

The session lifetime begins when the gateway first routes a request with a new session ID. The timer runs from that first request, not from when the session ID was created. At expiry, the gateway releases the IP assignment and routes the next request with that session ID through a new exit IP — the session transparently rotates. In-flight requests at the moment of expiry may go through either the old IP or the new one depending on timing and provider implementation.

There is no explicit session-end signal from the client. The gateway infers session end from inactivity or expiry. Operators who want to force a new IP mid-session — because the current exit IP has been flagged by the target — change the session ID to a new value, which triggers a fresh IP assignment from the gateway.

Exit node goes offline during the session. On residential pools, the enrolled device may disconnect from the network, switch from WiFi to mobile data and receive a different IP, or have the proxy SDK suspended by the OS. When this happens, the gateway has no path through the pinned IP. Depending on provider implementation, the session either breaks entirely or fails over to a new IP — which breaks session state at the target. The proxy connection log shows success; the application workflow does not.

Duration mismatch between proxy session and target session. If the proxy session expires at minute 15 and the target's session cookie is valid for 60 minutes, the target receives requests from a new IP at minute 15 and re-challenges or invalidates the session. The proxy rotated as configured. The target treated the IP change as a session anomaly. Fixing this requires setting the proxy session duration to exceed the target session lifetime — which may exceed the provider's maximum.

Geo-constrained session with insufficient pool depth. If the session requires a specific city-level exit IP and the provider's pool has no available IPs in that location at session renewal time, the gateway cannot maintain the pinned geo. The new IP may come from a different region, which some targets treat as a session anomaly.

Per-request rotation maximizes IP diversity and minimizes per-IP request concentration. The cost is session continuity — any target that ties state to the requesting IP breaks. Sticky sessions recover that continuity within the session window. The cost is IP diversity — all requests in the window use the same IP, which means IP-based rate limits apply again within that window. Sticky sessions do not eliminate the rate limiting problem; they trade breadth of IP exposure for continuity, which is only worthwhile if the target requires continuity.

Dedicated IPs are a permanent assignment — the same IP for the life of the subscription. Sticky sessions are temporary assignments — the same IP for minutes to hours, then rotation. Dedicated IPs are the right configuration for workflows that require persistent IP identity over days or weeks: account management, long-lived authentication sessions, SEO monitoring from a consistent origin. Sticky sessions are the right configuration for workflows that require continuity within a single workflow execution but benefit from fresh IPs between executions.

Some targets do not tie session state to the requesting IP — they use session cookies alone, validated independently of the origin address. Against those targets, sticky sessions add operational complexity with no benefit. The session would have held through rotation anyway.