Sticky vs Rotating Proxies: Which One Does Your Job Need?

One question settles sticky vs rotating: does the target remember you between requests? A workload table, a 60 second test and where each mode loses.

You are choosing between sticky and rotating because one of two things happened. Either a job that rotates freely started logging itself out, emptying carts or restarting paginated result sets, or a job that holds one address started drawing 429s and CAPTCHAs from a target that had been fine for weeks. Those are the two failure directions, they are mirror images, and the fix for each is the other mode. This guide is the decision, not the feature tour: the one question that settles it, a lookup table by workload, a test you can run in a minute, and what each mode costs you.

The one question that settles it

Does the target remember you between one request and the next?

If yes, that memory belongs to a session, and on most sites the session is loosely or tightly bound to the address it was created from. Change the address partway through and the target concludes it is talking to a different visitor. That is the whole case for stickiness, and it is the entire case: hold one exit for exactly as long as the conversation lasts.

If no, nothing on the server side links request seven to request six, so there is nothing for continuity to protect. Every connection can leave from a different exit, and the only thing you gain by holding one is a concentration of volume on a single address, which is precisely what per-address rate limits are built to notice. That is the whole case for rotation.

Most real jobs contain both answers at different steps, and the section on running both covers that. But the question is asked per conversation, never per project, and asking it that way is what makes the rest of the decision mechanical.

What a sticky proxy actually is

The phrase "sticky proxy" reads as if it names a product you can buy alongside datacenter and residential. It does not. A sticky proxy is a rotating proxy that has been told to hold. The pool, the gateway hostname, the credential and the price are the rotating plan's; what changes is a segment in the username that asks the gateway to keep resolving your requests to the same exit for a while.

On our rotating gateway that segment is -session-<id>, where the id is a string you invent. Same id, same exit, for up to 30 minutes counted from when the exit was first assigned. New id, a new pick from the pool. No API call creates the session and none tears it down, which matters more than it sounds: a worker that crashes mid-flow leaks nothing, because there was never a resource to release. The full grammar, the expiry behavior and the pattern for binding one worker to one id are in sticky vs rotating sessions; this guide stays on the question of when to use it.

Three modes, then, not two, and they sit on a line of increasing commitment to an address:

Rotating: a fresh exit per HTTPS tunnel, SOCKS5 connection or plain-HTTP request. You commit to nothing.
Sticky: one exit for the length of a task, minutes at a time. You commit to a conversation.
Static: one address that is yours until you replace it. You commit to an identity.

Sticky versus rotating is a decision made inside a rotating plan. Whether you need a static address at all is a different decision, made when a task outlives any sticky window, and rotating vs static proxies is where that one lives.

Sticky vs rotating by workload

The table is the decision procedure applied. Find your job in the left column; the right column is the mode and the reason.

Workload	Mode	Why
Public product or listing pages, no login	Rotating	Nothing is remembered; a held exit only concentrates volume
Search results, price checks, availability lookups	Rotating	Each page stands alone; spread is the whole point
Login, then read an authenticated dashboard	Sticky	The session cookie was issued to one address
Cart, address, payment	Sticky	Fraud scoring treats a mid-checkout network hop as a takeover signal
Multi-step forms, wizards, booking flows	Sticky	Partial progress is keyed to the session
Paginating a search that holds a cursor server-side	Sticky	A new exit can reset the cursor and hand you page one again
Managing one account for weeks	Neither	Longer than any sticky window: that is a static address
Sampling a target from many regions	Rotating	You want many identities, not one
Headless browser, one context per job	Sticky	Network identity and cookie state must change together

Two rows deserve a note. The pagination row is the one that hurts people, because every request succeeds at the HTTP layer and the damage only shows up as duplicated early pages and a missing tail in the output. And the "neither" row is where a lot of sticky trouble comes from: someone reaches for the longest session they can get, hits the ceiling, and concludes sticky sessions are unreliable, when the job was never a sticky job.

The 60 second test

Do not argue about which mode a target needs. Measure it.

First, confirm the two modes behave as advertised through your client. Through the rotating gateway, with the credential from the Proxies page of your dashboard:

# rotating: two connections, expect the addresses to differ
# (a repeat is legal; a pool is not a promise of distinctness)
curl -s -x http://USERNAME:PASSWORD@gw-rotating_datacenter.node4.io:8083 -H "Connection: close" https://api.ipify.org; echo
curl -s -x http://USERNAME:PASSWORD@gw-rotating_datacenter.node4.io:8083 -H "Connection: close" https://api.ipify.org; echo

# sticky: same id on both, expect the same address twice
curl -s -x http://USERNAME-session-job7c2f:PASSWORD@gw-rotating_datacenter.node4.io:8083 -H "Connection: close" https://api.ipify.org; echo
curl -s -x http://USERNAME-session-job7c2f:PASSWORD@gw-rotating_datacenter.node4.io:8083 -H "Connection: close" https://api.ipify.org; echo

Then run the actual flow twice: once rotating, once under a single session id. If it completes only under the session id, the target binds state to the address and the decision is made. If it completes both ways, the target keys its session on the cookie alone and you are free to rotate, which is cheaper and spreads your volume. If it fails both ways, the exit address was never your problem, and why is my IP getting blocked is the better starting point.

The reason for Connection: close in the first pair is that for an HTTPS target the gateway assigns an exit per CONNECT tunnel, and an HTTP client with keep-alive will happily send twenty requests down one tunnel and show you one address, which looks like a broken rotation and is not. IPv4 rotating proxies goes through that mechanism properly.

What each mode costs you

Sticky concentrates. Every request in the session lands on one address, so that address absorbs the full per-address rate limit of the target on your behalf. A sticky session that also crawls two thousand pages is a static proxy with extra steps, and it will be treated like one. Keep the pinned part of a job to the stateful part.

Sticky expires. A rotating datacenter pin is held for up to 30 minutes from first assignment, and a busy session does not extend itself. On the residential gateway the ceiling is 30 minutes on a best-effort basis: a household connection can drop at any moment, and a pin on a dropped device fails until the ceiling passes, so switch ids rather than wait. A worker that cannot restart its task from step one under a fresh id is a worker with a bug that has not fired yet.

Sticky depends on a session store. Holding a pin means the gateway has to remember it, and it does so in a shared store. If that store is unreachable, a request carrying a session segment is refused with a 503 rather than silently rotated, because silently rotating a request that asked to be pinned would produce exactly the mid-flow failure you were avoiding. Per-connection rotation is unaffected. If you see 503s only on session-carrying requests, that is the diagnosis.

Rotating churns identity. Per-connection rotation under a client that carries cookies presents one visitor arriving from dozens of networks in an hour. On a target that correlates cookie and address, that is a stronger signal than either alone. Clear the jar when you rotate, or scope one jar to each session id, and let network identity and browser identity move together.

Rotating spends bandwidth on retries. On a metered plan a failed request and its retry both bill. Rotating makes retrying cheap in terms of address reputation and does nothing to make it cheap in gigabytes, so cap retries on large payloads whatever mode you are in.

Neither changes classification. A datacenter exit is a datacenter exit whether it is held or rotated. A target that scores traffic by address type gives the pinned address the same score as the rotated one, and the only move that changes that score is a different pool, which is the case for residential exits and is a purchasing decision rather than a mode.

Run both in one pipeline

The mode is selected by the username you send, per request. Nothing about a plan commits you to one or the other, and nothing forces two processes.

import requests

GW = "gw-rotating_datacenter.node4.io:8083"

def proxy_for(session_id=None):
    user = "USERNAME" if session_id is None else f"USERNAME-session-{session_id}"
    url = f"http://{user}:PASSWORD@{GW}"
    return {"http": url, "https": url}

# discovery: stateless, rotate freely, no Session object so no cookies
listing = requests.get("https://target.example/listings?page=3",
                       proxies=proxy_for(), timeout=30,
                       headers={"Connection": "close"})

# conversation: log in and read the account under one held exit
s = requests.Session()
s.proxies = proxy_for(session_id="acct4182")
s.post("https://target.example/login", data={"u": "...", "p": "..."})
account = s.get("https://target.example/account")

The shape to notice: the stateless half uses no Session object at all, so it holds no cookies and reuses no connection, and the stateful half uses one Session with one id, so cookies and exit travel together. Deriving the id from the job (acct4182) means a retry rejoins the same conversation; salting it with an attempt number when the exit itself was the failure gives the retry a clean identity by construction. If you are on Scrapy, the same split belongs in proxy middleware rather than in each spider.

Where we lose, and where the market does

A sticky session on our rotating tiers is a datacenter address, held. That is the right tool for a checkout on a site with ordinary defenses and the wrong tool for a target that has already decided hosting ranges are not customers; no amount of holding fixes a classification problem. Residential pins are best-effort on every network including ours, because nobody owns the household router at the far end, and any vendor promising otherwise is promising something they cannot see. And the 30-minute ceiling is a real limit: a conversation that runs longer needs a fresh id, and a conversation that has to run for days needs a static address rather than a session.

None of that changes the decision procedure. Ask whether the target remembers you. If it does, hold an exit for the conversation and no longer. If it does not, rotate. Do both in one process when a job has both kinds of step, and pick the plan on the pricing page by volume rather than by mode, because every rotating plan carries both.