The starting point
The useful question is how long a workflow needs the same exit, and what your application should do when that continuity disappears.
Read the provider's definition of a session
Rotating and sticky describe exit selection policies. Rotating usually changes the assigned exit between requests, connections or time windows. Sticky requests affinity to one exit for a defined session. The trigger, duration and failover behavior depend on the provider; there is no universal username parameter for all services.
For example, Decodo documents per-request mobile rotation and configurable sticky sessions, while warning that an exit can disappear before the requested duration. Treat any provider's session duration as something to test, not a substitute for an application recovery path.
Align a session with a complete workflow
Consider a checkout test on your own staging store: load the product, add it to the cart and verify the delivery estimate. A practical starting point is one browser context and one proxy session for that entire scenario. Keep both consistent until the assertion finishes, then dispose of the scenario's state.
For independent regional availability checks, each check can be its own unit. Give every result the intended region, observed exit when available and timestamp. Do not assume that a newly selected exit is unique or that changing exits grants a higher request allowance.
Separate three kinds of state
Troubleshooting becomes clearer when the following are logged as separate, non-secret identifiers. A proxy session cannot restore a lost cookie jar, and a persistent cookie jar cannot force an unavailable exit to return.
- Application session: cookies, tokens and state owned by the destination.
- Client connection: a TCP connection or reusable connection pool.
- Proxy session: the provider's mapping from a session identifier to an exit.
Test expiry before raising concurrency
Choose a permitted diagnostic endpoint and make a few sequential requests inside the requested session window. Record the observed exit. Repeat after the documented expiry, and separately test a forced reconnect. Mark these as measurements from your sample, not a guarantee about the whole pool.
Decide what an early exit change means for your workflow: restart a read-only scenario, stop and report failure, or recover from a checkpoint. Do not automatically replay an operation that may already have created an order or changed account state. Put the recovery decision in the job specification before running many workers.
From reading to doing
Before you ship
- Define one complete workflow before selecting a session length.
- Keep cookie state and proxy affinity distinct.
- Test early exit loss and expiry with a small sample.
Sources & further reading
Technical references used for this guide. Check the documentation for your installed version and your provider’s supported configuration.