Rotating vs Sticky Proxy Sessions: Getting Rotation Right for Scraping

A scraper logs into a site, adds an item to a cart, gets two pages into checkout, and then gets logged out. Nothing in the code changed. What changed was the address underneath it. The proxy rotated in the middle of the flow, the site saw the same logged in cookie arrive from a new city, and it dropped the session. That single behavior, whether the proxy holds an address or swaps it, is what rotating and sticky sessions are about, and picking the wrong one is one of the most common ways a working scraper starts failing for no obvious reason.

I run proxy infrastructure and production scrapers, so this is a setting I have gotten wrong and had to fix, not a diagram off a vendor page. Rotating and sticky are not two products you buy. They are two ways of using the same pool. Here is what each one actually does at the proxy layer, how long sticky windows really last, and how I decide between them per job.

What a session actually is

Both settings revolve around one idea, so start there. To a site, a session is a sequence of requests it treats as one visitor. Two things carry that identity. One is the cookie the site handed you at login. The other is the address that cookie keeps arriving from. A careful site cross checks the two. So the identity your scraper presents is not just the cookie, it is the cookie and the ip together, and the moment those two stop agreeing, the site has a contradiction it can act on.

That framing is the whole article in one sentence. Rotation and stickiness are just choices about whether the address stays consistent with the cookie or not.

How rotation works at the proxy layer

Rotation means the gateway hands you a fresh address on some schedule, or a brand new one on every request. You point your client at a single endpoint, and behind that endpoint the provider swaps which upstream address your traffic actually leaves from. The goal is to spread load so no single ip gets hammered, and to keep any one address from building a reputation under your job.

For wide, stateless collection that is exactly what you want. Each page stands alone, there is no session to break, and spreading requests across many addresses keeps a single ip from tripping a rate flag. The cost is that rotation, by design, keeps changing where you appear to come from.

How a sticky session works

A sticky session is the opposite setting on the same pool. Instead of a fresh address each time, the gateway pins one address to you and holds it for a window. You usually request it by putting a session id into the proxy username, or by connecting to a dedicated sticky port. Every request you send through that token leaves from the same upstream ip until the window ends.

Under the hood it is a lease. When you send a session token, the gateway looks it up, reuses the address mapped to it, or picks one and remembers the mapping if there is none yet. Hold the token steady and you hold the address. Let it change or expire, and the gateway is free to hand you someone new. Like any lease, it has a length, and it runs out.

How long sticky windows really last

Sticky windows are shorter than most people assume. A lot of residential pools default to something in the one to ten minute range, and many let you request up to 30 minutes or an hour if you ask for it. Datacenter addresses can be held far longer, because you effectively own that address for the rental.

Residential and mobile stickiness is best effort. You are borrowing a real home line or a real phone, and that connection can drop at any time and take your window with it early. Mobile is looser still, because carrier networks reassign addresses on their own schedule and share each one behind nat. So the same sticky setting can give you a rock steady address on datacenter and a window that quietly resets on residential or mobile. Design for the address changing, not for it to last.

The two failure modes

Both failure modes come from mismatching the setting to the job.

Rotate in the middle of a stateful flow and you get the logout from the opening. You log in from one address, and two requests later the same session cookie shows up from a different ip in a different city. No real person teleports between clicks, so the site ends the session or throws a challenge. The flow breaks, and it looks random until you realize the address moved under you.

Hold one sticky address across a huge stateless crawl and you make the opposite mistake. You funnel thousands of requests through a single ip that a rotating pool was built to spread. That one address climbs the rate counters fast, earns a reputation by itself, and gets throttled or blocked while the rest of your pool sits idle. Stickiness concentrates trust on one door, which is wrong when the job never needed a door held open.

Keep one session’s identity together

A clean mental model prevents most of this. Treat one logical session as one bundle: a single session token, a single cookie jar, one consistent set of headers, all pinned to one address for the window. The bug I see most is a shared cookie jar bleeding across rotating addresses, so the same login state leaks out of three different ips inside a minute. That is a contradiction you built yourself.

Geography is part of that identity too. A sticky window should stay inside one city, and ideally one network, so a flow does not jump from a Singapore address to a US address halfway through checkout. Prices and availability shift by location, so a wandering session can also quietly corrupt the data you collect, not just get you flagged.

Concurrency does not require rotating inside a session

People worry that stickiness kills throughput. It does not, you just parallelize differently. Each sticky session is one worker holding one address for one flow. To run 50 logged in flows at once, you open 50 sticky sessions, each with its own token, address, and cookie jar. You get concurrency from many held addresses side by side, not from rotating inside a single session. Stickiness and scale are not in conflict.

How I decide per job

The decision comes down to one question: does this flow carry state the site ties to the address? If yes, a login, a cart, anything sequential, I go sticky and size the window to the length of the flow with a margin. If no, a wide stateless pull, I rotate, often on every request, to spread the load. Then I test on the real target, because a site can tie a session to the ip harder or looser than you would expect.

Two jobs I ran back to back make it concrete. One was a login gated account area, a few pages deep per visit. Rotating per request logged me out every second or third page, until a 10 minute sticky window let each visit finish clean. The other was a broad price crawl across tens of thousands of public pages. A sticky address there hammered one ip into a rate block within the hour, while per request rotation spread the same work quietly across the pool. Same tool, opposite settings.

The honest limits

Matching rotation to the job keeps your sessions intact and your load spread. It does not make anything undetectable, and no setting on a proxy does. It does nothing about a loud client, a bad tls handshake, or a request rate no human would produce. And it changes nothing about what you are allowed to collect. Public data, the robots file respected, an official api preferred where one exists, and whatever a site’s terms actually say. Rotation and stickiness are plumbing, not permission.

I run this infrastructure in production, so the way I pick between rotating and sticky here is the way I actually run the jobs. If you want the full written guides and the pools and settings I genuinely use, with real block rates and no undetectable promises, they are at dataresearchtools.com.

Get new guides and videos first — join the Telegram channel.