Rotating or sticky? Choosing how your IPs behave

Most people pick a proxy plan by network type and stop there. Residential or mobile, this many countries, that kind of bill. Then they wire it up and something behaves oddly, and they cannot tell whether the problem is the addresses or the way they are using them.

Often it is the second thing. The same credentials can send every request from a fresh address, or hold one address steady across a run. That single choice shapes whether a job feels smooth or fights you the whole way.

Two behaviours, one credential

Think of it as a dial rather than a product.

Turned one way, every request goes out from a different address. Nothing carries over. This is breadth: you spread activity across a wide surface, and no single address builds up a history that a site would notice.

Turned the other way, a run of requests keeps the same address for as long as you need it. Continuity: the far side sees a coherent visitor rather than a new stranger on every call.

Neither is better in the abstract. They are answers to different questions, and the trick is knowing which question your job is asking.

When rotating is the right call

Reach for per-request rotation when the work is wide and each request stands on its own.

Price checks across many listings. Availability sweeps over a catalogue. Discovery jobs that gather public data at scale, within the terms of the sites you visit, where the success of the run matters more than the success of any single call. In this kind of work there is nothing to remember between requests, so there is no reason to hold an address. Rotation lets you cover ground quickly and keeps any one address from carrying the weight of the whole job.

Premium Unlimited fits this shape. The pool is wide, the addresses turn over freely, and a broad discovery workload can run continuously without you counting each request. When you want reach and freshness above all, this is the setting to leave the dial on.

When a sticky session is the right call

The moment your requests depend on each other, rotation starts working against you.

Anything with steps. Signing in, then loading a page that only makes sense once you are signed in. Adding to a cart, then checking out. Filling a form across several screens. Following a flow where the site is tracking who you are from one request to the next.

Conceptually, a sticky session is a promise: for the length of this session, keep sending me out from the same place. You attach a session token to your requests, and everything carrying that token routes through the same address until you drop it or it expires. To the site, it reads as one visitor moving through one visit, which is exactly what a multi-step flow expects to see.

Does this request need to remember the last one? If yes, hold the session. If no, let it rotate.

That question resolves most cases on its own. A login remembers. A price lookup does not.

The failure you want to avoid

The costly mistake is rotating in the middle of something that needed to stay put.

Picture a cart. You add an item from one address, and the next request, meant to check out, goes out from somewhere else entirely. The site now sees a session that jumps location partway through. In the best case the flow simply breaks and you get an error. In the worse case it looks like exactly the kind of thing fraud systems are built to catch, and the account or the flow gets flagged.

None of that is the network misbehaving. It is a rotation setting applied to a job that wanted continuity. The addresses were fine. The dial was in the wrong position.

The reverse is gentler but still wasteful: holding one address for a job that had no state to protect. You give up breadth for a continuity nobody needed, and you make a wide job narrower than it has to be.

When you want the address to never move

Sometimes continuity is not a per-run decision but a standing requirement.

If a service remembers your address between visits, an account tied to a specific location, a dashboard that treats a new address as a new login to challenge, then even a sticky session that resets tomorrow is more movement than you want. What you want is a fixed address that stays yours.

Static ISP is built for that. A dedicated single-tenant US address that does not rotate at all, held for as long as you keep it. Where per-request rotation is breadth taken to its limit, a fixed address is continuity taken to its limit, and some work genuinely sits at that end.

A way to decide

Before you configure anything, ask what each request needs from the one before it.

If the answer is nothing, rotate, and let a wide pool do what it does best. If the answer is a shared identity for the length of a task, hold a session. If the answer is a stable identity that outlives any single task, use a fixed address and stop thinking about rotation altogether.

As with network type, this is a setting, not a commitment. The same credentials and the same dashboard carry across all three. If a job turns out to need more continuity than you gave it, or more breadth, you change the behaviour and run it again. The cost of getting it wrong the first time is a little rework, not a rebuild, so it is worth trying the obvious answer and adjusting once you see how the work actually behaves.