Sticky vs Rotating Sessions in 2026 — When Each Wins and How to Pick a Pool Strategy

The single most common misconfiguration we see on the customer side isn’t bad IP quality or wrong country selection. It’s the session strategy. People grab a residential pool, plug it into their scraper or agent with the default rotating mode, and wonder why their checkout flow keeps getting flagged. Or they configure sticky sessions for an aggressive scraping job, end up blasting one IP with 1,200 requests in 30 seconds, and trip every rate-limit on the target.

This post is the version of the conversation I have at least once a week with new customers. We’ll cover what each mode actually does, the workloads they each win for, the failure modes that get people stuck, and a flowchart you can run through in two minutes when wiring up a new pool. Most of it applies regardless of the brand under the hood — sticky and rotating aren’t supplier-specific concepts, they’re routing strategies on top of the pool.

What sticky and rotating actually mean

A residential proxy pool is a set of upstream IPs — typically tens of thousands to tens of millions, depending on the supplier — fronted by gateway endpoints. When you authenticate against a gateway and send an HTTPS request, the gateway picks one upstream IP to forward through. The two modes describe how that picking works on subsequent requests from the same authenticated session.

Rotating mode: every request can route through a different upstream IP. The gateway picks one fresh on each forward — sometimes constrained to a country or city, sometimes fully open. Your scraper hits page A, gets routed via IP 24.x.x.x. Hits page B, routed via 67.x.x.x. From the target’s perspective, request stream looks like a thousand different residential users, each making one request.

Sticky mode: once you bind a session token (typically a username suffix or header), the gateway pins one upstream IP to that session for some duration. We default to 10 minutes on most pools, configurable up to 30 in the dashboard. While the session is sticky, every request from your client to that session goes through the same upstream IP. From the target’s perspective, request stream looks like one residential user clicking around a site.

Some suppliers call these “high rotation” / “session-based” or “endpoint-mode” / “session-mode”. The behavior is identical; only the marketing differs. Bright Data, Oxylabs, Smartproxy, Iproyal, and the 14 residential brands we aggregate all expose roughly the same pair of modes via gateway parameters.

When sticky wins

Sticky sessions exist because some workloads break the moment your IP changes mid-flow. Three common patterns:

Multi-step checkout and account flows. A user adding an item to cart from IP X, then going to checkout from IP Y, then submitting payment from IP Z, looks like a hijacked session to any modern fraud system. Stripe Radar, PayPal Risk, Shopify Capital Bot Score, Klarna, Affirm — all of them treat IP discontinuity within a session as a strong fraud signal. Sticky for checkout is non-negotiable.

We see this fail constantly with agentic shopping bots. Customer wires up browser-use with the default rotating residential, agent navigates to product page successfully, adds to cart, hits checkout — and gets challenged or hard-blocked. They blame the pool. Switch to sticky, same pool, same target, same script: works on the first try.

Login + authenticated browsing. Most major sites tie session cookies to IP fingerprint. Login from IP X, request a protected page from IP Y, get logged out or 401’d. Twitter, Instagram, LinkedIn, Reddit, and basically every site with serious abuse pressure does this. Sticky is mandatory for any flow that requires authentication.

Anti-bot challenge solving. Cloudflare Turnstile, hCaptcha, DataDome challenge, PerimeterX interstitial — all of them work by issuing a token tied to your IP. Solve the challenge from IP X, present the token from IP Y, token rejected. Sticky duration needs to comfortably exceed the time-to-solve plus the validity window. 10 minutes covers most flows; 30 for slower captcha farms.

Geo-locked content with IP-based state. Some targets remember “you saw the Spanish version yesterday from a Madrid IP” and use that signal to skip the language picker on return. If you’re rotating, you keep getting the picker, which trips behavioral detection because real users don’t see it every visit.

API authentication flows that rate-limit by IP. OpenAI’s API, AWS signed requests, many SaaS APIs — they rate-limit per IP. If you’re rotating, your “spend” per IP is tiny but you’re touching the rate limit on every IP. Sticky concentrates spend, lets the IP build a reputation, and avoids cross-IP rate-limit interactions.

When rotating wins

The flip side. Rotating wins when the target is rate-limit aware and you need to spread load, or when freshness matters more than continuity.

High-volume scraping where pages are independent. Scraping a million product pages? Each page is its own transaction. Rotating one IP per request distributes the load across the pool and means no single IP looks like a scraper. The cost is you can’t maintain session state, but for stateless scrape you don’t need to.

Search engine scraping. Google, Bing, Baidu rate-limit aggressively per IP. Sticky is suicide here — even at 10 minutes you’d burn the IP after 50-100 SERPs. Rotating with a residential pool, one IP per query (or one IP per page of results), is the standard pattern. Pair with sufficient query spacing and good user-agent variation.

Ad verification. When you’re verifying that ads serve correctly across geographies, every check should look like an independent user. Rotating per check is exactly what you want — and you typically want sub-country geo control too (city or zip), since some campaigns target by metro area.

Price scraping for retail/airline/hotel. Targets are aggressive about IP+browser fingerprint correlation. Same IP scraping price twice in five minutes = bot. Same IP doing one price check, never returning = noise. Rotating wins. We see customers run F-Geofast and similar fast pools at one-request-per-IP for travel meta-search scraping; that’s the standard configuration.

SEO / brand monitoring. Crawling your own site or competitor sites to check rank, content, broken links. Rotating residential prevents your scraper from showing up in target analytics as a single suspicious IP that keeps hitting every page.

Sneaker, gaming, ticket release flows. Counterintuitive but: pure release moment is rotating. The site has zero state to maintain (you haven’t been there before), and burning each IP after one request maximizes your chance of getting a single successful slot. Once you have an in-cart, switch to sticky for checkout. We cover this pattern in detail in our sneaker proxy guide.

The failure modes that catch people

A few patterns we see often enough to call out explicitly:

Sticky too long. Sticky for 30 minutes on a checkout flow that takes 4 minutes wastes 26 minutes of IP per session. Multiply by concurrency and you blow through the pool’s available unique-IP budget. Tune the sticky duration to roughly 1.5x the longest expected session length.

Sticky too short. The opposite. 1-minute sticky on a 4-minute checkout flow means the IP rotates mid-payment, triggering exactly the fraud signal you tried to avoid. Always test with curl --proxy your_gateway:port https://ipinfo.io/ip repeated every 30 seconds during a real session to verify the IP doesn’t actually change before checkout completes.

Rotating without enough geo diversity. If your pool only has 5,000 unique IPs in the country you’re targeting and you’re sending 50 requests per second, the pool churns through its full set in 100 seconds. From the target’s perspective, after 100 seconds you start hitting “fresh” IPs that are actually IPs they saw 100 seconds ago — and modern anti-bot tracks this. Match pool size to your request rate.

Mixing modes in one script accidentally. Your library has a default session ID that varies between threads. Two threads sharing one session end up reusing the same sticky IP for concurrent requests, which looks weird (one IP doing 5 things at once). Make sure each parallel worker has its own session token if you’re sticky, and verify by logging the IP from inside each worker.

Trusting sticky duration documentation. Some upstream suppliers under-deliver — they say 10 minutes but the IP changes after 4 minutes because the upstream peer dropped off. Always measure empirically. We monitor this on our own pools and rebalance traffic when a brand can’t hold the documented sticky window; many of our supplier integrations have brand-specific notes on this in the residential dashboard.

A quick decision tree

When configuring a new pool, walk through this:

1. Does your workflow span multiple requests that must look like one user? Yes → sticky. No → rotating.
2. If sticky, what’s the longest expected single session in your workflow? Set sticky duration to 1.5x that, capped at the brand’s maximum.
3. If rotating, will you send more than ~5 requests/second sustained? Yes → choose a pool with at least 5x your request rate in unique active IPs.
4. Does the target challenge with Cloudflare/DataDome/PerimeterX? If yes and the challenge takes >1 minute to solve, force sticky regardless of workflow type — challenges that span IP rotations always fail.
5. Are you scraping a search engine or ad-served target? Force rotating, one IP per query at minimum.
6. Are you logging in? Sticky, period.

This isn’t theoretical — it’s a digest of the tickets we resolve every week. Most customer “the pool doesn’t work” reports turn out to be the wrong mode, not bad IPs.

Implementation patterns

The gateway parameter for switching modes is supplier-specific but follows a few common forms. The convention on most brands we aggregate is to embed a session ID in the username:

# Rotating (no session ID)
curl -x http://USERNAME:PASS@gateway:port https://ipinfo.io/ip

# Sticky 10-minute session
curl -x http://USERNAME-session-abc123:PASS@gateway:port https://ipinfo.io/ip

Some brands use a header (X-Proxy-Session: abc123) instead of a username suffix. Some put the rotation interval in the username (-rotate-30m). The dashboard exposes the right format for each brand under My Proxies; if you copy the generated URL from there, mode is set correctly by default.

For agentic workloads we recommend using a fresh session ID per agent task and rotating on task boundaries — so each task feels like one human session, but successive tasks don’t share IP fingerprints. browser-use, Playwright, and Selenium all support per-context proxy configuration; configure a new session ID when you spawn a new browser context.

What we actually default customers to

When customers don’t know which to pick:

• Scraping (most common request): rotating, residential pool.
• Agentic browsing / checkout / login flows: sticky, residential pool, 10-min session.
• Bulk price comparison across many sites in one job: rotating, residential, fast brand.
• Ad/SEO verification with geo precision: rotating, residential with city/zip targeting.
• Sneaker/ticket release: rotating during release, sticky after in-cart.
• API rate-limit bypass for our own legitimate work: sticky, ISP static — IP reputation matters more than rotation.

If you read this and realize you’ve been on the wrong mode for what you’re doing, switching is one parameter. Test on the same pool first before assuming the pool itself was the problem. Eight times out of ten, the pool was fine and the mode was wrong.

—

Sara has been doing anti-bot research and pool engineering at Hell World since the early days. If you want to talk through a tricky session strategy question for your stack, the Discord server #engineering-help channel is the fastest way to reach her or someone on the team.