Rotating vs Sticky Proxy Sessions: How to Choose

A proxy session is the identity you hand to a target site. In rotating mode the provider gives you a different exit IP for each new connection. In sticky mode you pin one exit and keep it for a defined window. Both run through the same gateway hostname, the same credentials and usually the same port. What changes is a few characters in the proxy username.

The choice comes down to state. If the target has to remember something about you between the first request and the second, both requests need to leave from the same address. If it does not, every additional request from that address is a free signal that something automated is on the other end.

Two modes, one gateway

Residential networks are almost always sold as a backconnect gateway: one hostname, one port, and a pool of exits behind it. Nothing about rotation lives in your code. The gateway reads your username, selects a matching exit, and relays the request. If you have read what are residential proxies, this is the hop where the rotation flag gets interpreted.

The detail that catches people out is that rotation is per connection, not per HTTP request. The gateway assigns an exit when the TCP connection is established and holds it for the life of that connection. Any HTTP client with connection pooling turned on, whether that is a Python requests.Session, an axios keep-alive agent or Go's default transport, will send request after request down the same socket and therefore out of the same exit. Rotating credentials plus keep-alive behave like a series of short sticky sessions, and your requests-per-IP count climbs without anything in your code changing.

If you want a genuinely new address per request, close the connection or send Connection: close and accept the handshake cost. If you want throughput, keep the pool and treat each socket as a small session with its own budget. Doing one while believing you are doing the other produces block rates nobody on the team can explain.

How a session ID is encoded in the proxy username

The username field is a parameter bus. Country, city, ASN, session key and sometimes session lifetime are all packed into it as hyphen-separated pairs, because a standard HTTP proxy handshake gives you nowhere else to put them. Four patterns cover nearly the whole market.

# Rotating: no session parameter, so a new exit is chosen per connection
curl -x http://user-cc-us:[email protected]:7000 https://echo.example/ip

# Sticky: an opaque key you generate, reused for every request in the task
curl -x http://user-cc-us-sessid-cart7f3a1c:[email protected]:7000 https://echo.example/ip

# Some gateways want the lifetime declared explicitly, in minutes
curl -x http://user-cc-us-sessid-cart7f3a1c-sesstime-10:[email protected]:7000 https://echo.example/ip

# Others map one sticky exit per port instead of encoding it in the username
curl -x http://user-cc-us:[email protected]:10042 https://echo.example/ip

• The session key is yours to invent. Providers treat it as an opaque string. Reuse the same string and you get the same exit; change one character and you get a different one.
• Keys are scoped to your account. A key of session1 used by two of your own workers is one shared exit, not two. Derive keys from something unique per task, such as a cart ID or a job UUID.
• Some gateways need the lifetime stated through a parameter like sesstime, in minutes. Omitting it usually falls back to the provider default rather than to rotating behaviour.
• Port-per-session gateways allocate a block of ports where each port holds one exit. Handy for tools that cannot edit the username, awkward once you need more concurrent sessions than the block has ports.
• Geo parameters combine with session keys. Pin the country first and the session second, so that a replacement exit is still drawn from the right place. The proxy geotargeting guide covers the precedence rules.

How long sticky actually sticks

Advertised sticky windows cluster between 1 and 30 minutes, with ten minutes the most common default. A few providers offer several hours, and a few will hold an exit for as long as the underlying device stays connected, which is the honest way of describing what the software is really doing.

Treat the advertised number as a ceiling. The lifetime you get is the shortest of three things: the provider TTL, how long that household device stays online and reachable, and whatever internal rebalancing the provider performs. Consumer devices reboot, hand off from Wi-Fi to LTE, and get new DHCP leases. A 30-minute window on a peer-to-peer pool is a hope rather than a contract.

When you need an exit that survives for days, sticky residential is the wrong product. Static ISP addresses are announced from provider hardware and stay where they are; ISP proxies explained covers the trade-off in pool size. Mobile pools sit at the opposite extreme, where carrier-grade NAT means the address is shared with thousands of subscribers and can change without notice, as mobile proxies explained describes.

Where each mode fails

Both modes fail loudly once you point them at the wrong workload, and the two failure signatures look nothing alike.

Rotating: state that never survives

A login POST returns a Set-Cookie from exit A. The follow-up GET leaves through exit B carrying that cookie. Any session bound to the client address is invalidated immediately, and you receive a 302 back to the login page or a 403 while holding what looks like a perfectly valid cookie. CSRF tokens, cart identifiers, pagination cursors and single-use checkout nonces all break the same way, and none of them produce an error message that mentions proxies.

Rotation also hides trouble. Because failures land on a different address every time, a target that has quietly started serving soft blocks looks like a pool with a mildly elevated error rate instead of a target that has stopped answering you. Instrumenting for that is the subject of proxy success rate explained.

Sticky: one address carrying too much

Rate limits are enforced per address. A sticky exit that serves an entire crawl will earn a 429 with a Retry-After, or something worse: silently degraded responses and challenge interstitials delivered with a 200 status. Once that address is flagged, the flag outlives your window, and retry logic that keeps aiming at the same session key keeps feeding the flagged exit.

Concurrency is the other trap. Thirty workers sharing one session key present a single household making thirty simultaneous requests, which no residential user does. Providers also apply their own per-exit concurrency caps, so you often hit gateway errors before the target sees anything at all. More patterns for keeping request shape plausible are in how to avoid getting blocked web scraping.

Recovering when a sticky exit dies mid-session

The instinct is to retry the request that failed. That is usually wrong, because the cookies you are holding belong to an address no longer in your path, so you spend bandwidth to receive a second failure. Handle the event as session loss instead:

1. Detect at the application level. Assert on something only a genuine authenticated response contains, because a soft block arrives with a 200 and your status-code check will pass.
2. Read the exit IP back and compare it with the one you started on. Many gateways expose it in a response header; where they do not, hit a cheap echo endpoint once at session start and cache the value.
3. Discard the cookie jar, the CSRF token and every server-issued identifier. All of them are bound to the dead exit.
4. Mint a new session key rather than reusing the old one. Reusing a key that just failed frequently returns you to the same degraded slice of the pool.
5. Replay from the last idempotent checkpoint instead of from the request that failed, and cap replays per task so that one bad exit cannot turn into a bandwidth bill.

Picking a mode by workload

One rule settles almost every case: one session per logical actor. A cart is an actor. A logged-in account is an actor. A page fetch in a stateless crawl is not an actor, so it should not get a session.

Hybrid patterns that hold up in production

Mature scrapers run both modes at once rather than picking a side. Four patterns come up repeatedly.

• Session pool. Keep somewhere between 50 and 200 sticky sessions alive and hand them out like database connections. Each task borrows a session, returns it, and any session that fails twice is retired instead of retried. You get requests-per-address low enough to look human and enough spread to hold throughput.
• Two-tier crawl. Rotate for discovery work such as sitemaps, listing pages and anything anonymous. Switch to a sticky session only for the authenticated or multi-step part of the job. This keeps the expensive stateful surface as small as possible.
• Rotate the session, not the request. On a 429, do not retry harder. Retire the session key, wait out the Retry-After value, and resume the task on a fresh exit with fresh state.
• Log the exit address with every record you store. When a target starts returning odd prices or truncated listings, being able to group your own results by exit turns a week of guessing into one query.

Verifying rotation behaviour before you build on it

Provider documentation describes intent. A trial measures behaviour. Four checks take under an hour each and regularly contradict the docs.

1. Send 200 requests with one fixed session key to an IP echo endpoint and count distinct addresses. Anything above one means the window is not holding for the duration you were sold.
2. Repeat with no session parameter at all and count distinct addresses again. A low count here means the rotating gateway is reusing exits far more aggressively than the advertised pool size suggests.
3. Hold one session open and probe every 30 seconds until the address changes. That interval, not the marketing figure, is the window you can design against.
4. Run the same test twice, once with keep-alive enabled and once with it disabled. The gap between the two distinct-address counts is how much rotation your own HTTP client is cancelling out.

We run rotation and session checks continuously as part of the live benchmark, from both US and EU infrastructure, and the procedure is written up in our methodology. Gateway hostnames and session syntax for each network live on its profile page, for example NodeMaven. To line several pools up against each other before you commit, use the provider comparison tool; the full evaluation programme, including trial design and pricing normalisation, is in how to benchmark proxy providers.