Rotating vs Static Proxies Explained

IP persistence sits on a spectrum with three useful points. At one end: rotating, where every request exits through a different residential IP drawn from the pool. In the middle: sticky sessions, where one IP is pinned to a session ID for a fixed time window. At the far end: static IPs — addresses assigned to you semi-permanently, typically ISP proxies hosted in datacenters but registered to consumer internet providers.

The platform operates a residential pool of 16M+ IPs across 195+ countries, sourced from a consenting, compensated bandwidth-sharing network, and covers the first two points natively. If you are new to how residential pools work, start with what residential proxies are — the rest of this article assumes that background.

Rotating is the default behavior. Send ten requests, get ten different exit IPs. There is nothing to configure and no session state to manage — the pool handles assignment on every connection.

• Breadth: each request exits from a different node, spreading your load evenly across the pool instead of piling it onto one peer.
• Geo spread: combined with country or city targeting, each request can exit from a different node in the same region.
• Zero bookkeeping: no session IDs to generate, track, or expire.

The same property makes rotating terrible for anything stateful. Sites commonly bind a session cookie to the IP that created it; when your next request arrives from a different address, the session is invalidated. Login flows, shopping carts, multi-step forms, and paginated results behind an authenticated session all fall apart under per-request rotation.

A sticky session pins one residential IP to a session ID you invent. Append -s-<id> to your proxy username; every request carrying that ID exits through the same IP. The password never changes — only the username carries parameters.

# rotating (default): a new IP per request
user123-cc-US

# sticky: same IP for 10 minutes under session id 'checkout1'
user123-cc-US-s-checkout1-ttl-600

The default hold is 60 seconds. Add -ttl-<seconds> to extend it, up to 86400 — twenty-four hours. Size the TTL to the real length of the workflow: a login-plus-scrape task that takes three minutes needs -ttl-300, not the maximum.

A true static IP — usually sold as an "ISP proxy" — is an address leased from an internet provider and assigned to you for weeks or months. It survives reboots, weekends, and everything in between. That is a different product from a residential pool, and it is worth being precise: a sticky session is not a static IP.

With the platform you get pool-based residential access with sessions pinned for up to 24 hours. When the TTL expires, the IP goes back to the pool. The exit node is also a real peer device on a real consumer connection, so treat sticky sessions as strong best-effort continuity within the TTL window, not a permanent address you own.

If your workload genuinely needs one fixed address for weeks — for example, an address you register with a partner API you are authorized to use — a residential pool is the wrong tool, and you should weigh a static ISP product instead. For everything session-shaped, twenty-four hours of stickiness covers the practical cases.

• Crawling breadth — large volumes of public pages, price or SERP snapshots, one request per URL: rotating. Let the pool spread the load.
• Login flows and carts — authenticate, act, check out: sticky, with a TTL sized to the full flow and a unique session ID per account or task.
• Retail monitoring plus checkout — mixed mode: rotating for high-frequency stock monitors, sticky for the checkout path. The sneaker proxies guide walks through this split in detail.
• Long-lived identity — the same IP needed across days or weeks: ask honestly whether a pool fits at all. Sticky tops out at 24 hours; beyond that you are shopping for static ISP proxies, not residential rotation.

A handful of failure patterns cause most "broken session" problems.

• Rotating through a login flow. The credential form posts from one IP, the redirect lands from another, and the site drops the session. Symptom: logins that succeed but immediately bounce back to the sign-in page. Fix: use a sticky username for every step of the flow.
• One session ID shared across concurrent workers. Twenty threads all using -s-main exit through a single IP — one node becomes a single point of failure for the whole workload, and when the TTL expires every worker changes IP at once. Fix: a unique ID per worker, e.g. -s-worker7.
• Relying on the default TTL. Without -ttl-, a sticky session holds for only 60 seconds. Tasks that run longer rotate silently mid-flow. Set the TTL explicitly.
• Treating sticky as static. Do not build anything that assumes the same IP tomorrow. Design for the TTL window and re-establish sessions cleanly when it ends.

You do not need to hand-build usernames. The proxy generator in the dashboard produces both flavors in any of seven output formats, from user:pass@host:port to a custom template.

1. 01Open the Proxy Generator in the dashboard and choose rotating or sticky, then set the quantity of lines you need.
2. 02Add geo targeting if the task needs it — country, continent, city, or ASN.
3. 03Generate up to 50,000 lines, then copy or download the list.
4. 04Run a sample through the built-in Proxy Checker to confirm live IPs, countries, and latency before pointing production traffic at them.