Rotating vs sticky sessions: which one does your job actually need?
By The Masklabs team
Every credential on Masklabs can run in two modes, and you choose per request, not per account. Get this choice wrong and you'll either burn IPs a site doesn't expect to see change, or keep hammering a target with the same exit until it's rate-limited. Here's how each mode works and when to reach for it.
Rotating: the default
Send a request with your credential as-is, no suffix, and you get rotating behavior: a fresh upstream IP on every single request. There's nothing to configure. It's the mode you're in the moment you create a credential, and it's the right default for most scraping work.
mlabs_a1f9c3:<PASSWORD>@proxy.masklabs.io:8080
Two requests through that login can land on two different exit IPs. Ten requests can land on ten. That's exactly what you want when you're pulling pages across many independent targets, or hitting one target hard enough that any single IP would get flagged after a handful of hits.
Sticky: pin one IP for about a minute
Append _sticky to the login and the gateway pins you to the same upstream IP
for roughly 60 seconds:
mlabs_a1f9c3_sticky:<PASSWORD>@proxy.masklabs.io:8080
Same credential, same password, you're just adding a suffix at connect time. There's no dashboard round-trip and no separate sticky "session ID" to generate and track; the suffix on the login string is the whole mechanism. After the window elapses, the next request on that login gets a new pinned IP for a fresh minute.
When rotating is right
Reach for rotating whenever each request stands on its own:
- Bulk page fetches. Pulling product listings, search results, or article pages across a large target set, where no single request depends on the session state of the last one.
- High request volume against one target. If you're making hundreds of requests to the same site in a short window, rotating spreads that load across many exits instead of hammering one.
- Anything stateless. If the site doesn't set a session cookie you need to keep, or doesn't care whether request 2 comes from the same IP as request 1, rotating is simpler and costs you nothing extra.
When sticky is right
Reach for sticky whenever the target needs continuity across requests:
- Login flows and multi-step checkouts. A site that ties your session cookie to the IP that created it will bounce you if the IP changes mid-flow. Pin it for the duration.
- Pagination on a stateful search. Some search backends key results (or anti-bot scoring) to the requesting IP across a page sequence. Stay on one IP until you've walked the pages.
- Anything that fingerprints IP churn. A target that treats "same session, new IP every request" as a bot signal wants the opposite of rotating.
Mixing both from one team pool
Because the mode is a per-request suffix and not an account setting, one
credential can run both ways depending on what you append, and different
credentials on the same team pool can run different modes simultaneously.
A common pattern: a scraper-prod credential doing high-volume rotating
fetches, and a separate checkout-flow credential running sticky for the
handful of requests that need session continuity, both drawing from the same
GB balance, each with its own usage line in the dashboard.
The bottom line
Default to rotating unless you have a specific reason to pin. The reason is almost always "the target needs to see the same IP across a sequence of requests", a login, a checkout, a paginated session. Everything else is rotating's job, and it's also the cheaper mental model: no session to expire, nothing to track beyond the credential itself.