Sticky Sessions
Why the generator applies sticky sessions automatically, how the per-endpoint session id works, and when you would want a rotating address instead.
Last updated
A sticky session means the same endpoint keeps the same exit IP for the life of the session, rather than the address changing between requests.
The generator applies this automatically. There is no toggle, because there is no sensible alternative for the endpoints it produces.
How it works
Every generated endpoint carries its own session identifier. Two properties follow.
Each endpoint holds its own address. Generate five endpoints and you get five different exit addresses, not five endpoints sharing one. This is why generating several is a reasonable way to get several concurrent identities.
Each endpoint keeps its address for the session. Requests through one endpoint do not silently move to a different address halfway through a task.
Sessions are created per endpoint, so replacing one endpoint gives that one a new address and leaves the rest alone.
Why it matters
An endpoint whose address changes mid-task causes three kinds of failure, all of them annoying to debug.
| Failure | What you see |
|---|---|
| Session invalidated | A login or multi-step flow stops working partway through |
| Travelling identity | A task appears to originate in several places in quick succession |
| Inconsistent results | A price or ranking check returns a mix of locations |
Sticky sessions remove all three for the duration of the session. That is why they are the default rather than an option.
Long-running tasks
A session has a practical lifetime. If a task runs longer than a single session comfortably allows, and the address must not change, a static address is the better fit. Static addresses hold one IP for as long as you keep them, which is the right choice for account work where identity stability matters more than anything else.
For a task that only needs a stable address during the work itself, an endpoint's own session is enough.
When you want rotation instead
There are cases where changing address is desirable.
High-volume public fetches. Reading many public pages spreads better across changing addresses than through one.
Recovering from a burned address. When one address starts being refused, a fresh one fixes it, which is what Replace does for a single endpoint.
Load spread across a large set. Where there is no session to protect, variety in source addresses is useful.
None of those change the default, because all of them are about read-only work rather than about holding an identity. Rotating a logged-in session remains something to avoid.