Rotating vs Sticky Proxies: Choosing the Right Session Type

Rotating proxies give you a new IP address on every request. Sticky proxies keep the same IP for a set time, so a multi-step flow such as a login, a search with several result pages, or a checkout comes from one address. Use rotating sessions for independent requests at scale, and sticky sessions whenever the target ties requests together with cookies or server-side state. On our residential, mobile and unlimited gateways, you switch between the two with a single username parameter.

How rotating sessions work#

With no session parameter, the gateway picks a fresh peer for each request. Run this twice and you get two different IPs:

curl -x http://gw.proxonym.com:8000 -U "USERNAME-country-us:PASSWORD" https://api.ipify.org

Rotation has three benefits. Load spreads across the pool, so per-IP rate limits are rarely reached. A blocked IP costs you one request, not a whole job. And your requests look like many unrelated visitors, which is what they are. The cost is continuity: anything that depends on the same visitor coming back, such as a shopping cart, a login or a server-side search cursor, can break.

How sticky sessions work#

Add -session-{id} to the username and the gateway keeps the same IP for every request that carries that ID. The ID is any string of 1 to 32 letters and digits that you choose. Add -lifetime-{minutes} to set how long the IP is held; without it, a sticky session lasts 10 minutes.

# The same New York IP for up to 30 minutes
curl -x http://gw.proxonym.com:8000 \
  -U "USERNAME-country-us-city-new_york-session-a7k2-lifetime-30:PASSWORD" \
  https://api.ipify.org

Reuse the ID within its lifetime and you get the same IP; change the ID and you get a different one. To check, run this loop: it prints the same IP three times. Remove -session-test1 and it prints three different IPs.

for i in 1 2 3; do
  curl -s -x http://gw.proxonym.com:8000 -U "USERNAME-session-test1:PASSWORD" https://api.ipify.org; echo
done

The maximum lifetime depends on the product:

Residential peers are real devices, so a peer can go offline before a session's lifetime ends. The gateway then returns 502. Retry once; if the session keeps failing, start a new session ID and, for logged-in flows, sign in again.

Choosing a session lifetime#

Set the lifetime to the longest time one flow needs, plus a margin. Longer is not safer: an IP that gets flagged halfway through stays with you until the session ends, and a long session gives its peer more time to drop.

Check the request count per IP as well. A worker that sends one request every two seconds on a 30-minute session sends 900 requests from one IP. If the target starts challenging an IP after a few hundred requests, shorten the lifetime or slow the worker down. Lifetime and request rate together decide how hard each IP works.

Examples: scraping vs login flows#

Scraping a product catalog: rotating#

Product pages are independent. Each request can come from a different IP, and a block on one page does not affect the next. Leave out the session parameter, target the country whose prices you want, and let failed requests retry on a new IP.

A logged-in flow: sticky#

A login sets a cookie that many sites bind to the IP that created it. Seeing that cookie arrive from a different IP on the next request is a classic sign of session hijacking, and the site may log the user out or ask for verification. Keep the IP and the cookie jar together for the length of the flow:

import secrets
import requests

def sticky(country, minutes):
    sid = secrets.token_hex(6)   # 12 letters and digits
    url = (f"http://USERNAME-country-{country}-session-{sid}-lifetime-{minutes}"
           ":[email protected]:8000")
    return {"http": url, "https": url}

proxies = sticky("gb", 20)
with requests.Session() as s:   # one cookie jar, one IP
    s.post("https://example.com/login", data={"email": "...", "password": "..."},
           proxies=proxies, timeout=30)
    orders = s.get("https://example.com/account/orders", proxies=proxies, timeout=30)

Only automate logins to accounts you own or are authorized to use. More patterns, including retries and timeouts, are in the Python requests proxy guide.

Sticky per task, rotating across tasks#

Most real jobs mix both. A rank tracker gives each keyword its own short sticky session, so pages 1 to 3 come from one visitor while different keywords use different IPs. A headless browser needs a sticky session for every identity, because a single page load pulls dozens of resources that should all come from one IP; see Puppeteer and Playwright proxies.

Rotating every N requests#

Some targets tolerate a short burst from one visitor but not hundreds of requests. A middle ground is to keep each IP for a fixed number of requests, then switch:

import secrets

class SessionRotator:
    """Return the same session ID for per_ip requests, then a new one."""

    def __init__(self, per_ip=20):
        self.per_ip, self.used, self.sid = per_ip, 0, secrets.token_hex(4)

    def username(self, country):
        if self.used == self.per_ip:
            self.used, self.sid = 0, secrets.token_hex(4)
        self.used += 1
        return f"USERNAME-country-{country}-session-{self.sid}-lifetime-10"

Create one rotator per worker so that workers never share an IP, and tune per_ip to what the target tolerates.

Pitfalls to avoid#

• One session ID for every worker. If 50 threads share -session-1, they share one IP and hit rate limits together. Give each worker or task its own ID.
• Predictable IDs across scripts. Two jobs that both use -session-1 end up on the same IP. Generate random IDs.
• Changing parameters mid-flow. Keep the whole username identical for the life of a session, including the country and city.
• Kept-alive connections on rotating jobs. Connection pooling can pin an IP, as described above. If rotation matters, close connections between requests.
• Rotating IPs with persistent cookies. Either clear cookies between requests or use a sticky session. A stable cookie on a changing IP is the worst of both.
• Expecting long sessions from mobile. Mobile sessions last up to 3 minutes. Use residential, unlimited or ISP proxies for longer flows.

The full parameter reference, including -state-, -asn- and -type-mobile, is in the documentation.

Key takeaways#

• Rotating: no session parameter, a new IP per request. Use it for independent pages at scale.
• Sticky: -session-{id} plus -lifetime-{minutes}. Use it for logins, carts, pagination and browsers.
• Keep lifetimes as short as the flow allows: up to 120 minutes on residential, 12 hours on unlimited, 3 minutes on mobile.
• Use one random session ID per worker or task, and never share IDs across jobs.
• For an identity that must last days, use static ISP proxies instead of sessions.