Guide
Rotating vs sticky sessions: when to use each for scraping
Updated 2026 — written for people who run real crawlers.
A surprising number of scraping failures come down to one call made the wrong way: rotating when you should have stayed put, or staying put when you should have rotated. The two modes don't substitute for each other, and the wrong pick gets you blocked, throttled, or quietly handed garbage data. Here's how to tell which one a job actually wants, so you can stop guessing.
What the two modes actually do
A rotating session gives you a fresh exit IP on every request — the gateway draws a new address from the pool each time your code makes a call. A sticky session does the reverse: it pins one IP to a session token and holds it for a set TTL, so every request under that token exits the same address until the timer runs out. Same gateway, same credentials. The only thing that changes is whether the IP stays put or moves.
When to rotate per request
Rotate when the target rate-limits per IP and your requests don't depend on each other. This is the high-volume case: product catalogs, search-result pagination, price monitoring across thousands of pages. Each request stands alone — no login, no cart, no cookie that has to survive. Spread that load across a large mobile pool and no single IP ever piles up enough requests to cross a threshold, so the crawler runs hot while no one address looks abusive.
Rotation also bails you out when a target challenges or soft-blocks individual IPs. If one exit catches a captcha, the next request is already on a different IP, so a single bad address never stalls the run. For stateless, parallel, high-throughput work, rotate-per-request is the right default nearly every time.
When to use a sticky session
Stick when the target ties state to your IP. Anything that runs across several requests and expects continuity wants one stable address: logging in, working through an authenticated dashboard, adding to a cart and checking out, or walking a multi-page form. Change the IP mid-flow and the target sees a session hopping between networks — which is exactly the anomaly anti-bot systems are built to catch.
Sticky also fits QA and screenshot work, where you want a steady vantage point, and any scrape that has to finish a handshake before it can read anything. Set the TTL to comfortably outlast your longest flow and the IP holds the whole way through.
The mistakes that get you blocked
The classic slip is rotating inside a logged-in flow. You authenticate on IP A, the next request lands on IP B, and the target kills the session — real users don't teleport between carriers mid-checkout. The opposite slip is staying sticky for a million-page crawl: one IP soaks up all that volume, trips the per-IP limit, and drags the whole job into throttling. Match the mode to the request pattern and both problems just go away.
Mixing both in one workflow
The best crawlers use both. One worker can open a sticky session to log in and pull account-specific pages, then drop the token and fan out per-request for the bulk crawl that follows. Since both modes live on the same gateway, switching is just a property of the request — not a rewrite. You can even hold a sticky IP and force a rotation on command, after a 429 or a checkout or on your own schedule, getting stability and spread inside one run.
The short version
Stateless and high-volume? Rotate per request. Stateful and multi-step? Use a sticky session. Both in one job? Switch per request and let the gateway sort it out. Get this one call right and most of your scraping reliability headaches take care of themselves.