Rotating and sticky sessions

Leave the session suffix off and each new connection is matched to a different exit device. This suits work where every request stands alone: search results, product listings, price checks.

The unit of rotation is the connection, not the request. A client that reuses a pooled connection keeps the address it started with until that connection closes, which is why a scraper can report one address for minutes at a time.

Add a session identifier and the exit holds for the lifetime you set. Three lifetimes are available and the choice should follow the task rather than habit.

Thirty seconds covers a login and its redirect. Fifteen minutes covers a checkout or a multi-step form. One hour covers account warming and anything where a mid-session address change logs you out.

Lifetimes are ceilings rather than guarantees. Residential exits are real household devices and can drop earlier, so handle reconnects instead of assuming the full hour.

The identifier is yours to choose and costs nothing. Give every worker, profile or account its own number and they hold separate addresses in parallel.

Two workers sharing an identifier share an exit, and their behaviour merges from the destination point of view. That is the most common cause of accounts being linked despite a correct proxy setup.

The decision is rarely about preference. Each task either survives an address change midway or it does not, and that answers the question.

Anything with a cart, a login, a multi-step form or a queue needs stickiness for its whole duration. Anything where each request stands alone should rotate, because rotation is what keeps rate limits away.