Glossary

What Is a Sticky Session?

A sticky session is a proxy configuration that pins the same exit IP to a client for a defined window or for the lifetime of a session ID, instead of rotating to a new IP per request.

Understand why session continuity matters for login flows, paginated scraping, and checkouts, and how to use sticky sessions without giving up the benefits of a rotating IP pool.

Explained

A sticky session is the opposite of per-request IP rotation: rather than picking a new exit IP for every request, the proxy gateway pins one IP to your traffic for the duration of a session. The session is typically scoped by a session ID you pass in the proxy username (e.g. `customer-USER-session-abc123`) and lasts until the gateway's stickiness window expires (commonly 1, 5, 10, or 30 minutes).

Sticky sessions are essential for any workflow where the destination site binds state to the source IP. Login pages, multi-page checkout flows, IP-bound CSRF tokens, paginated search results, and most account-management tasks all require the same IP across multiple requests. If you used per-request rotation, the second request would land on a different IP and the destination would treat it as a new, unauthenticated visitor.

Most residential proxies proxy providers expose both modes through the same gateway. You opt into stickiness on demand by including a session ID in the proxy auth, and you opt out by removing it.

How It Works

When you connect to a rotating proxy gateway with a session ID in your auth credentials, the gateway hashes the session ID and binds it to a specific exit IP from the pool. All subsequent requests using the same session ID are routed through that IP until the stickiness window expires or the IP becomes unhealthy.

When you change the session ID (or stop sending one), the gateway picks a new IP. This gives you per-workflow stickiness without losing the diversity benefit of the pool — different workflows running in parallel each get their own pinned IP, while still drawing from the same large rotating pool.

Types

Time-Bounded Sticky Session

The IP stays pinned for a fixed window (commonly 1, 5, 10, or 30 minutes). After the window, the next request gets a new IP. Standard configuration for most scraping pipelines.

Session-ID Bounded Sticky Session

The IP stays pinned for as long as the client keeps using the same session ID. Lets you control session lifetime explicitly from the client side.

Dedicated / ISP Proxies (Permanent Stickiness)

Not technically 'sticky sessions' but the same effect: an ISP / dedicated proxy gives you a single IP you keep indefinitely, suitable for long-lived account-management workflows.

Common Use Cases

Logged-in scraping (sessions bound to the IP)
Multi-page checkout flows
Paginated search-result scraping
Account management on social platforms
Workflows with IP-bound CSRF tokens
Any flow where mid-session IP changes break state
FAQ

Frequently asked questions

Common questions about sticky session.

Most residential proxies providers offer sticky sessions in the 1 to 30-minute range. For longer-lived sessions (hours or indefinite), use ISP / dedicated proxies, which give you a permanent IP for the lifetime of your subscription.

Pass a session ID in the proxy username, like `customer-USER-session-myworkflow-1`. Shifter's gateway will pin that session ID to a specific residential IP for the configured window. Reuse the same session ID across requests to keep the IP; change it to get a new IP.

Use sticky sessions when the workflow needs the same IP across multiple requests (logins, pagination, multi-page flows). Use rotating (per-request) when each request is independent (search-result scraping, single-page product fetches at scale).

Not guaranteed. Sticky sessions are bound for the configured window; once that window expires, the gateway is free to assign a new IP even if you reuse the session ID. For permanent IP stability, use ISP proxies instead.

Yes. Each session ID gets its own pinned IP from the pool, so you can run hundreds of parallel sticky sessions, each with a different IP, all through the same gateway. This is the standard pattern for multi-account workflows.

Most gateways will rotate you to a new IP automatically if the current one fails health checks (becomes unreachable, gets flagged, or drops). The session ID stays the same; the underlying IP changes. Your client should be prepared to retry on transient failures.