Rotating or sticky residential sessions: pick by what you are doing, not by habit

Most people pick a session type once, early, and then never revisit it. Rotating felt safer, or sticky felt more stable, and it became the default for everything. Then a job that should work starts failing and the session type is the last thing anyone suspects.

The choice is not a preference. It follows from one question: does the job have state? If a site needs to remember you between requests, you need the same address twice. If it does not, you want each request to look unrelated to the last.

This guide is about making that call deliberately, and about what a sticky session actually promises, which is less than most people assume.

Start with what the job needs

Ask whether anything has to survive between one request and the next. A login, a cart, a multi step form, a paginated result set that is tied to your session: all of those break if the address changes underneath them.

If nothing has to survive, rotation is the better default. Each request arriving from a different address is the normal shape of residential traffic, and it spreads your load instead of concentrating it on one device.

If the job has state, use a sticky session. If it does not, rotate.

Rotating: a fresh address per request

With rotation, each request goes out through a different address from the pool. You do not manage it, you do not track it, and you do not need to know which address served which request.

This is the right shape for fetching pages that do not care who is asking. Product pages, listings, search results, anything you could fetch from a different machine tomorrow and get the same answer.

The thing to watch is volume per target. Rotation spreads your requests, but it does not make them invisible. If you send a thousand requests a minute at one site, that site sees a thousand requests a minute from a thousand addresses, and the pattern is still obvious.

Sticky: one address for a window

A sticky session pins your requests to one address for a period you choose. Everything inside that window goes out through the same device, so a login survives, a cart survives, and a sequence of steps looks like one visitor.

The window is the whole decision. Too short and the session drops mid flow, which is worse than never having had one. Too long and you are holding one address for far longer than a real visitor would, which is its own signal.

A sticky session pins which address you get. It does not promise that address never changes.

That distinction matters more than it sounds. Residential addresses belong to real devices, and real devices go offline, lose signal, or get rebooted. When that happens you are moved to a fresh address, and a job that assumed continuity has to cope. Build the retry, do not assume it away.

The comparison

	Rotating	Sticky
Address per request	Different each time	Same for the window
State across requests	None	Preserved
Good for	Listings, search, bulk fetch	Logins, carts, multi step flows
Main risk	Volume pattern per target	Address changing mid flow
Best default	Stateless fetching	Anything with a session

Where the two get mixed up

The most common mistake is using rotation for something that has state. It usually shows up as a login that works and then a second page that returns you to the login screen, because the second request arrived from a different address than the first.

The second most common is the reverse: holding one address for a whole crawl because sticky felt safer. That concentrates everything on a single device, which is slower and looks nothing like normal traffic.

A third one is worth naming because it catches people out. On some plans, setting a time to live without naming a session still creates stickiness for that period, so a configuration that reads like rotation behaves like a pin. If your traffic is not behaving the way the setting suggests, that is the first thing to check.

Choosing a window

Pick the shortest window that covers the job. A single login and a few page loads is minutes, not hours. A long running process that genuinely needs continuity is the only reason to hold an address for a long stretch.

If you are unsure, start short and lengthen it when you see sessions dropping mid flow. Starting long and shortening is the harder direction, because by then you have built assumptions on top of it.

What this does not cover

Two honest limits.

First, a sticky session is about which address you get, not about where that address is. If your job needs a specific city, that is a targeting question and it is answered on the plans that support it. Do not assume every plan offers per request city or ASN selection, because they do not.

Second, session type does not fix a target that has decided it does not want you. If a site is blocking you on behaviour, the address is not the problem and changing how it rotates will not help. That is a different post.

The short version

Look at the job, not the habit. If something has to survive between requests, pin it. If nothing does, rotate it. Keep the window as short as the job allows, and build for the address changing underneath you, because eventually it will.

If you are still deciding which plan fits the work, the comparison between per gigabyte and per port pricing is the next thing to read, and how many proxies you actually need covers sizing once you have picked. For the wider question of which network suits the job, ISP or residential is the place to start.