Sticky vs Rotating Proxy Sessions: How to Choose

The difference in one line

A rotating session gives you a new IP for every request. A sticky session keeps the same IP for a set period, or until you ask for a new one.

Both come from the same rotating proxy pool. The difference is how you tell the gateway to behave, usually with a session parameter.

How sticky sessions work

Most residential and mobile providers let you pin an IP by adding a session ID to your username:

customer-acme-country-us-session-a1b2c3
customer-acme-country-us-session-a1b2c3-sesstime-20

All connections that use the same session ID are routed through the same exit IP, for as long as the provider allows (often 1, 10 or 30 minutes; some offer hours) or until the exit device goes offline. To get a new IP, change the session ID.

Note the caveat. With residential proxies, the exit device is a real consumer device. If its owner closes their laptop, the session ends early and the gateway either errors or assigns a new IP. Good providers try to keep long sessions on more stable devices, but no residential sticky session is guaranteed. If you need an IP that never changes, use static residential (ISP) proxies.

When to use rotating sessions

• Scraping independent pages: product pages, search results, listings.
• Checking prices or availability across many locations.
• Any stateless request where you don't need cookies to persist.
• Maximising the number of distinct IPs your traffic is spread across.

When to use sticky sessions

• Logging into an account and performing actions.
• Adding to cart and checking out.
• Browser automation, where a page loads dozens of sub-resources that should come from the same IP. See Puppeteer proxies.
• Passing a bot-protection challenge and then reusing the clearance cookie.
• Paginating through search results that are tied to a session.
• Any multi-step form.

Recommended session lengths

Common mistakes

• Rotating during login. The site sees a login from Texas and the next request from Ohio. Account flagged.
• Sharing a session ID across parallel workers. Many concurrent connections on one residential IP looks unnatural and may overwhelm the device.
• Sessions that are too long. If an IP gets blocked, a long session keeps you on a bad IP. Detect blocks and switch session IDs.
• Assuming sticky equals static. It isn't. Plan for session drops with retry logic.

Handling session failures

Build your code to detect a broken or blocked session and create a new one:

import uuid, requests

def new_proxy():
    sid = uuid.uuid4().hex[:8]
    url = f"http://customer-acme-country-us-session-{sid}:PASS@gate.example.com:7777"
    return {"http": url, "https": url}

proxies = new_proxy()
for url in urls:
    r = requests.get(url, proxies=proxies, timeout=30)
    if r.status_code in (403, 429) or "captcha" in r.text.lower():
        proxies = new_proxy()  # rotate to a fresh IP

For more patterns, read proxy rotation strategies.

Worked examples

Example 1: Scraping 10,000 product pages

Each product page is independent. Use rotating sessions, one new IP per request. Disable keep-alive or use a new session ID per request so connection reuse doesn't keep you on one exit. Retry failures with a new IP.

Example 2: Paginating search results

Page 2 of a search may depend on cookies set on page 1. Use a sticky session per search query, 2 to 5 minutes long, and rotate between queries.

Example 3: Logging into an account and downloading reports

Use a static IP (ISP proxy) or the longest sticky session available. A login from one IP followed by downloads from another looks like session hijacking. See static residential proxies.

Example 4: Passing a bot challenge, then scraping

The site sets a clearance cookie after a JavaScript challenge, tied to the IP. Use a sticky session for as long as the cookie stays valid, scraping as many pages as the site tolerates per session, then rotate.

Session parameter syntax varies

Providers use different names and formats. Examples of the same idea:

Read your provider's docs and use their generator to avoid typos. See proxy authentication methods.

Monitoring session health

Log the exit IP at the start of each sticky session and periodically during it. If the IP changes unexpectedly, the device went offline and the provider reassigned your session. Frequent changes mean you should shorten sessions, change targeting, or switch to ISP proxies for that workload.

Choosing good session IDs

The session ID is a small detail that causes a surprising number of problems. A few rules keep it boring:

• Make IDs random and unique per task. Something like uuid4().hex[:8] works. Sequential IDs (1, 2, 3) collide across scripts and teammates sharing an account, and a collision puts two unrelated jobs on one IP.
• Add a short readable prefix. shopa7f3k2q tells you in logs which job owned the session. Keep the prefix short; some gateways limit username length.
• Respect the provider's character set. Many gateways accept only letters and digits in the ID. Hyphens and underscores are often parameter separators in the username itself, so keep them out unless the docs allow them.
• Never put personal data in an ID. It travels in the username and lands in the provider's logs and yours.
• Don't deliberately reuse old IDs. Some gateways remember a recent session-to-IP mapping, so yesterday's ID might hand you an IP your job already burned.
• Map accounts to sessions on purpose. For account work, store which account uses which session or static IP in a register, so the same account always returns to the same exit. See social media management proxies.

Session IDs are also the cleanest way to give each worker its own exit when you scale out. Puppeteer rotating proxies shows the browser version of this pattern, and antidetect browser proxies covers pairing sessions with browser profiles.

Session controls differ a lot between providers, from fixed 10 minute sessions to custom lengths. Check them against your workload when you compare providers in our best proxies in 2026 guide.

Comparing two popular self-serve providers? Webshare vs Geonode Sticky Sessions breaks down which fits this job and when it makes sense to use both.

If you're weighing Rayobyte as well, Rayobyte Sticky Sessions explains which of its products fits, and Rayobyte vs Geonode vs Webshare Sticky Sessions Compared puts it side by side with Geonode and Webshare.

FAQ

What's the maximum sticky session length?

It varies by provider. Thirty minutes is common; some offer several hours. Always check, and remember that residential devices can drop sooner.

Do sticky sessions cost more?

Usually not. Traffic is billed the same per GB. Some providers charge more for very long sessions or premium stable IPs.

Can I get the same IP back after a session ends?

Sometimes, if you reuse the session ID within a window, but don't rely on it. Use ISP proxies when you need a fixed IP.

Sources and further reading

Independent references that back up the points above, from standards bodies, governments, universities and non-profits. They open in a new tab.

• CAPTCHA (Wikipedia): The history of CAPTCHA challenges, from Carnegie Mellon to today.
• Automated Threats to Web Applications (OWASP): OWASP's catalogue of automated threats, including scraping and scalping, as site owners see them.
• RFC 6265: HTTP State Management Mechanism (Cookies) (IETF / RFC Editor): The cookie standard, which ties a session together regardless of IP.
• RFC 9110: HTTP Semantics (IETF / RFC Editor): The HTTP standard that defines how proxies, tunnels and the CONNECT method behave.
• Retry-After header (MDN Web Docs (Mozilla)): The header that tells clients how long to wait before retrying.