Session mode

Sticky session proxies

One address held across a sequence of requests, so a multi-step flow does not change identity halfway through.

Pick this when

A sequence of requests has to look like one visitor.

Set with: Rotation 0, alongside a session identifier
Identifier: A string you choose, up to 128 characters
In parallel: Several named sessions on one credential pair, each holding its own address
Bounded alternative: A 5 to 60 minute window releases on a schedule instead of on idleness

How it works

You pass a session identifier when building the connection, and requests carrying that identifier keep the same outbound address.

This is what a login, a cart or a checkout needs. Rotating mid-flow generally invalidates the state the site is holding for you.

Sessions are named, so several can run in parallel under the same credentials — each holding its own address.

How it differs

Against its nearest neighbours, by name. If one of these describes your situation better, the row is a link.

Where it fits

Use it for

Authenticated sessions that must persist across requests
Multi-step flows — search, then filter, then paginate
Any workflow where a mid-sequence IP change would drop server-side state

Do not use it for

High-volume stateless collection, where holding one address concentrates traffic on it
Work that benefits from spreading requests widely — use per-request rotation instead
Jobs that open a session per item and never close one, which runs you into the session ceiling

Sticky sessions concentrate your traffic on fewer addresses. Use them for the part of the job that needs continuity, and rotate for the part that does not.

A real connection

One credential pair covers everything. Type, country, rotation and session all travel inside the username, so you never provision a second proxy user to change one of them.

Hold one IP for a named session

user-USERNAME-type-residential-country-it-session-cart_7f2-rotation-0

Requests carrying the same session value keep the same address. Run several named sessions in parallel on one credential pair, each holding its own IP.

Questions

How long does a sticky session last?: It holds while you keep using it. For a bounded window instead, use timed rotation — 5 to 60 minutes — which releases the address on a schedule rather than on idleness.
How many sessions can I run at once?: Several, distinguished by the identifier you choose. There is a ceiling, and the network answers with a session-limit error rather than quietly reusing an address — so treat a session as something you open and release, not an unbounded pool. One session per concurrent worker scales; one per item does not.
What if the address goes offline mid-session?: On residential and mobile this can happen — the underlying connection is not yours. Write the workflow so a step can be retried, rather than assuming an address will survive an arbitrarily long job.
Should I use sticky for everything?: No. Sticky concentrates your volume on fewer addresses, which is the opposite of what stateless collection wants. Use it for the part of the job that needs continuity.

The same on every type

These four do not vary by proxy type, so they are worth stating once rather than six times. One balance covers all of it.

See pricing

Protocols: HTTP, HTTPS and SOCKS5
Targeting: Country, then state or city; ASN by number
Rotation: Per request, sticky, or 5 / 10 / 15 / 20 / 60 minutes
Rate: $2/GB, sent plus received

Where this comes up

The other half of the same username

Where the address comes from

Pick exactly one.

All proxy types