Rotating or sticky sessions: how to choose

The choice comes down to one question: does the next request depend on the one before it?

What each mode does

With rotation, every request can leave from a different IP. With a sticky session, requests carrying the same session ID stay on one IP for the time you set. On our network, the difference is a suffix on the proxy username: -session-ab12cd-time-10.

Use rotation when requests stand alone

Checking 500 product pages, or one search query per location, involves no shared state. Rotation spreads requests across addresses, and a failure on one IP does not touch the next request. It is the default for a reason, and it needs no session management in your code.

Use a sticky session when requests belong together

Some flows break if the address changes halfway: a browser loading a page and its resources, pagination that stores state in a cookie, or a selected region that the site ties to a session. Keep those requests on one IP.

How long should a session be?

As long as the flow needs and no longer. A short duration, such as a few minutes, is enough for most page flows. A long session raises the chance that the home connection behind it goes offline, and it concentrates your requests on one address.

Plan for the IP going away

A residential IP is someone's home connection, so it can disappear. Do not write code that assumes it will not. When a request in a sticky flow fails, restart the flow with a new session ID rather than retrying forever on the old one.

A simple rule

1. Start with rotation.
2. If the job fails because state is lost between requests, group those requests into a sticky session.
3. Generate a new session ID for each flow, not one for the whole job.

The proxy URL generator creates a list of URLs with separate sessions.