Sticky session

Rotating pools change exit address constantly, which is right for scraping and wrong for anything logged in. A sticky session pins a session identifier to one address for a chosen window, so a sequence of actions appears to come from one place.

How stickiness is actually requested

Two conventions dominate. The first encodes parameters into the username you authenticate with — a string of the shape user-country-us-session-a1b2c3-sesstime-30, where the session token is any value you invent and the duration is expressed in minutes. The second assigns one port per session: the provider opens a range, and each port in it holds a distinct address for you.

The consequence of the first convention is worth stating plainly, because it surprises people. The session token is a label, not a lease. Reusing the same token after the window has closed does not return you to the old address — it opens a new session that happens to share a name. Nothing errors, and nothing tells you the address changed.

Why an account needs it

Logging in from Frankfurt, loading a page from São Paulo and posting from Singapore inside four minutes is not a plausible sequence for any human. An account that changes IP mid-session looks worse than one that never moves at all — rotation without stickiness actively creates the anomaly it was meant to avoid. A move within one ISP’s own pool is mild; a move across autonomous systems and countries while carrying the same session cookie is the version that gets a session challenged.

Choosing a duration, and what breaks at the edges

Match the window to the task. A login and a handful of actions may need ten minutes; a warm-up session running for an hour needs the full hour, or a static ISP proxy instead. Note that stickiness is best-effort on residential pools: the underlying consumer device can drop offline before the window ends, and the provider substitutes a new address silently rather than returning an error.

The failure therefore never announces itself as a proxy failure. It shows up as an upload that dies at eighty percent, a login that bounces back to the login screen, a session that suddenly starts asking for verification, or a task that completes but on an account that is challenged an hour later. If you are not recording the exit address, none of those symptoms points at the network.

Verifying stickiness yourself

• Open a session, query an IP echo, and store the address, ASN and country as the session baseline.
• Poll the same echo every thirty seconds for the full advertised window — sixty samples over thirty minutes — and count how many times any of the three values change. A provider advertising thirty-minute stickiness that moves twice inside it is one you route around rather than argue with.
• In production, re-check the exit before each action that matters and abort rather than proceed if it moved. A skipped post costs nothing; a post from the wrong country costs the account.
• Log the exit address alongside every action, so a ban weeks later can be traced back to the moment the address changed.

Three errors worth naming

• Treating an advertised duration as a guarantee rather than a ceiling.
• Letting an idle gap run past the window and resuming with the same session token, which quietly opens a new session on a new address.
• Assuming a rotation moves everything at once. Connections already open stay on the old exit while new ones use the new address, so a single page load can genuinely arrive from two places.

For accounts meant to live in one place indefinitely, stop managing sessions and buy a static address. It costs more per month and removes an entire class of failure.