Sticky Sessions and Rotation: Keeping the Same IP

Connect to <proxy-host>:80 with your plain username and password and you get rotation: each request is assigned a fresh IP from a pool of 16M+ residential addresses across 195+ countries. There is nothing to enable and no rotation interval to tune — the unit of rotation is the request itself.

This is the right mode for breadth. If each request is independent — fetching many public pages, checking prices across regions, collecting search results — a new IP per request spreads your traffic thin and no single address carries your whole workload.

# Rotating: run this twice and the exit IP changes
curl -x "http://user123:pass@<proxy-host>:80" https://example.com/

A sticky session pins one exit IP for the lifetime of the session. You create one by appending -s-<id> to the proxy username, where <id> is any session identifier you invent. The password stays unchanged. Every connection that presents the same session ID is routed through the same IP while the session lasts.

Session length is controlled by -ttl-<seconds>. Without it, a session lasts 60 seconds. The maximum is 86400 — twenty-four hours. Sticky parameters combine with geo targeting in the same username, for example -cc-US before the session parts.

user123                                rotating (default)
user123-s-job42                        sticky, 60s default TTL
user123-s-job42-ttl-600                sticky, 10 minutes
user123-cc-US-s-job42-ttl-3600        sticky US IP, 1 hour

# Same IP on both requests while the session lives
curl -x "http://user123-s-job42-ttl-600:pass@<proxy-host>:80" https://example.com/
curl -x "http://user123-s-job42-ttl-600:pass@<proxy-host>:80" https://example.com/

The session ID is yours to define, and it is the whole control surface. The rules are simple:

• Same ID, live TTL — you resume the same IP. Reconnects, parallel connections, and retries with the same ID all land on the same exit address.
• New ID — a new session and a new IP, immediately. Rotating the ID is how you deliberately switch addresses mid-run.
• Expired TTL — the pin is gone. Reusing the old ID afterward starts a fresh session, which will generally sit on a different IP.

Use one unique, random-looking ID per logical session — per account, per browser profile, per worker thread. Keep IDs strictly alphanumeric: username parameters are hyphen-delimited, so a hyphen inside the ID can produce a username the parser misreads. Something like acct8f3a91c works well. Avoid a single shared ID across workers: every worker would funnel through one IP, which defeats the point of a residential pool. Avoid predictable reused names like test for the opposite reason — you may resume a session you thought was finished.

Choose sticky whenever the target associates state with your connection. If your IP changes between the step that sets the state and the step that uses it, the flow breaks.

• Logins and authenticated browsing — the session cookie is issued to one IP; keep using it from that IP.
• Carts and checkouts — multi-step purchase flows expect one consistent visitor.
• Multi-page forms and wizards — server-side state tied to your session.
• Paginated result sets — walking page 1 through page 40 as one coherent visit.

Choose rotating for the inverse shape: many small, stateless, independent requests where breadth matters more than continuity. A common pattern is both at once — a rotating pool for discovery, and a sticky session spun up whenever one target requires a stateful, multi-step interaction.

Residential IPs belong to real devices in a consenting bandwidth-sharing network, and real devices go offline — a laptop sleeps, a phone leaves Wi-Fi. When the peer behind your session disappears, the session can end before its TTL runs out, and your next request exits from a different IP. Treat the TTL as an upper bound, not a guarantee.

Build your automation so an early IP change is an inconvenience, not a failure:

1. 01Verify the session where it matters: at checkpoints in a long flow, confirm you are still authenticated (or check the exit IP) rather than assuming continuity.
2. 02Keep re-login logic ready: if the target's session breaks with the IP, start a fresh sticky session with a new ID and repeat the login step.
3. 03Retry idempotent steps automatically; for non-idempotent steps such as submitting an order, check whether the action completed before repeating it.
4. 04Persist workflow state outside the session so a restart resumes from the last checkpoint instead of the beginning.

If sessions seem to drop far more often than expected, or sticky requests are not holding an IP at all, work through troubleshooting proxies — the usual causes are malformed username suffixes or an expired TTL rather than pool churn.

Match the TTL to the length of the workflow, with a little headroom. A scripted login-and-fetch that finishes in two minutes fits comfortably in -ttl-300; a long interactive browsing session may justify the full -ttl-86400.

• Short TTLs release IPs back to the pool promptly, keep stale pins from lingering, and limit how long a problem session can affect your run.
• Long TTLs suit genuinely long workflows, but a twenty-four-hour pin on a two-minute task is waste — and the longer the window, the more opportunity for the peer to drop mid-session.
• Uncertain duration? Size the TTL to the longest plausible run of the flow, and design for re-pinning: when the session expires mid-run, start a fresh sticky session with a new ID and resume from your last checkpoint.

Rotation for breadth, sticky for state, unique IDs per logical session, TTLs sized to the job, and retry logic for the day a peer goes dark — that covers nearly every session-handling decision you will make on this network.