sticky vs rotating sessions
Sticky vs rotating sessions: when to use which
Pick the wrong session mode and logins fail for no visible reason, or simple scraping gets blocked for no good reason. There is really only one test.
One test: do requests depend on each other
If request two needs state left by request one — a login, a cart, a multi-step form, a pagination cursor bound to a session — use sticky.
If every request stands alone and replaying it from a different IP gives the same result, rotate. That is the whole decision.
How sticky sessions work
You attach a session identifier to your credentials, and the gateway pins requests carrying that identifier to one exit IP for the session lifetime. When it expires, or when you change the identifier, you get a new exit.
Managing those identifiers is your job. One business identity per identifier: do not share one across accounts, and do not generate a fresh one per request, which is the same as not using sticky at all.
Sizing the session lifetime
Base it on how long one complete flow actually takes and add thirty to fifty percent headroom. Do not just max it out.
Too short fails visibly: the IP changes mid-flow, the server decides the session is bogus, and you get kicked. Too long fails invisibly: behavior piles up on one IP until it looks automated.
Rotating does not have to mean every request
Real users hold one IP for a browsing session. A request sequence that obviously belongs to one visit but changes IP repeatedly is itself a signal.
The middle ground is short-lived stickiness: one identifier per browsing session, held for tens of seconds to a few minutes, rotating between sessions. You get the spread of rotation with a behavior pattern closer to a person.
Stop deliberating, run one test
Still unsure after reading? Buy the minimum and run it against your real targets.