Two support tickets, opposite problems. One person is scraping a catalog and gets a security checkpoint halfway through login because his IP changed under him. The other is running a wide crawl, got handed a single IP for the whole job, and watched it get banned inside an hour. The first needed a sticky session. The second needed the opposite, a fresh IP per request. Same rotating gateway, one setting apart, and it decides whether the job works.
We run a proxy network, so here is the setting explained properly: what a sticky session is at the mechanism level, why holding an IP is the only thing that keeps a login alive, and how to know which mode a given task needs.
The knob: how often does your IP change?
A rotating proxy gives you one gateway endpoint that draws exits from a pool (we cover that architecture in what is a rotating proxy). Sitting on top of that architecture is a single choice about frequency:
- Per-request (rotating) sessions assign a new exit IP for every request. Each request is anonymous to the last. You look like a fresh person every time.
- Sticky sessions pin one exit IP in place for a timed window, then rotate it away when the window ends. You look like one person for as long as the window lasts.
Everything else about the two modes, what they are good at, where they fail, follows from that one difference in how long you keep an IP.
What a sticky session actually is
A sticky session is not a different pool or a premium tier. It is a hold placed on the normal rotating pool. You ask the gateway for one, typically by putting a session identifier into your username (a token like session-a1b2c3 alongside your country and other parameters) or by connecting to a dedicated sticky port. The gateway reads that token, picks one exit, and then keeps mapping that same token to that same exit for every request that carries it, until an internal timer expires.
When the timer runs out, the mapping is dropped. Send the same token again afterward and you get a different exit, because the old one has gone back into the general pool. This is the detail people miss: the token does not own the IP, it only reserves it for a window. Two facts fall straight out of that. The IP is temporary, so you cannot come back to it tomorrow. And because the exit is usually a real home line, it can vanish before the window is up, so treat the window as a ceiling on how long you might hold the address, not a promise that you will.
Why holding the IP is what keeps a login alive
To understand why sticky sessions exist at all, you have to know what a website does with your IP after you log in.
When you sign in, the server hands your browser a session, usually as a cookie that every later request carries so the site knows the requests are all still you. Plenty of sites go one step further and tie that session to the environment it was born in. OWASP's session management guidance recommends exactly this: "bind the session ID to other user or client properties, such as the client IP address, User-Agent, or client-based digital certificate," and it spells out the consequence. "If the web application detects any change or anomaly between these different properties in the middle of an established session, this is a very good indicator of session manipulation and hijacking attempts, and this simple fact can be used to alert and/or terminate the suspicious session."
Read that as a proxy user and the failure mode is obvious. Log in on one IP, let per-request rotation send your very next request from a different IP, and the site sees your session jump addresses mid-flow, which is precisely the hijack pattern that control is watching for. The result is a re-authentication prompt, a security challenge, or a killed session. A sticky session prevents it by making sure every request in the login sequence leaves through the same IP, so the property the site bound your session to never changes underneath it.
OWASP is honest that IP binding is not a perfect defense (shared NATs and proxies mean many real users share an address, so sites cannot lean on it alone), and that cuts both ways: it is a detection signal, not a wall, but it is a signal you trip loudly the moment your IP moves mid-session. Do not hand it a reason to look.
When per-request rotation is the right mode
Flip to the other side. For work where each request stands on its own, per-request rotation is the better mode, and for the same reason sticky is worse there: you want maximum spread across IPs. A crawl that pulls ten thousand product pages has no session to protect, so pinning to one IP only concentrates all ten thousand requests onto a single address, which is the fastest way to cross a per-IP rate limit and collect a 429 Too Many Requests, the rate-limiting status code sites return when one source asks for too much too fast. Rotate every request instead and those ten thousand hits scatter across two thousand exits, none of them conspicuous. No session to break, every reason to keep moving.
Sticky is not static, and the gap is expensive to get wrong
The most costly mix-up in this whole topic is treating a long sticky window as a stand-in for a static IP. They are not interchangeable.
| Sticky session | Static IP | |
|---|---|---|
| What it is | A timed hold on a rotating-pool IP | One fixed IP assigned to you |
| How long it lasts | Minutes, then it is gone for good | The length of the plan |
| Can you return to the exact IP | No, once the window ends it is released | Yes, it is always the same address |
| Right for | A task that completes in minutes | An identity you keep for days or weeks |
| Sold as | A rotating-proxy feature | ISP / static residential proxies |
If a job has to look like the same person across a workday, or hold an account logged in for a week, no sticky window covers it, and stretching the window is the wrong instinct. That is static-IP territory, which we cover as a purchase decision in rotating vs static residential proxies, and which our ISP proxies are built for. Sticky is for a sequence that starts and finishes inside one window. Static is for an identity that outlives any window.
A one-look decision guide
Walk your task down this and stop at the first match:
- Does it log in, hold a cart, or chain several requests that depend on each other? Sticky, with a window long enough to cover the whole sequence.
- Does the identity need to persist for hours or days? Not sticky at all. Use a static ISP IP.
- Is it high-volume collection where each request is independent? Per-request rotation, for the widest spread and the lowest chance of hitting a rate limit.
- A mix of both in one project? Split them: per-request rotation for the collection layer, sticky (or static) for the account layer. Running both through one setting is how half your pipeline ends up with the wrong tool.
Our residential gateway supports both modes on the same endpoint, so you set per-request or a sticky window per job rather than buying a different product for each, and our proxy checker confirms which IP a session is actually exiting from when you need to verify the hold is working. Match the frequency to the shape of the task, and the sessions stop fighting you.
Sources and further reading
- OWASP, "Session Management Cheat Sheet". Recommends binding a session ID to the client IP and other properties, and explains that a mid-session change is treated as a hijack indicator that can terminate the session, which is why a changing proxy IP breaks logins.
- RFC 6585: Additional HTTP Status Codes. Defines
429 Too Many Requests, the per-IP rate-limit response that per-request rotation is designed to spread out and avoid. - Xianghang Mi et al., "Resident Evil: Understanding Residential IP Proxy as a Dark Service", 2019 IEEE Symposium on Security and Privacy, for the pooled, real-device nature of the exits behind a sticky or rotating gateway, and why any single exit can drop mid-window.