Sticky sessions

Without a session id every request may leave from a different address. When a workflow needs continuity (a login, a cart, a paginated result set), give it a session id and it holds one address, for up to as long as you say.

Sticky or rotating

Every new connection is given an exit address before your first byte moves. A sticky session keeps its exit address, so repeat requests skip that setup. On a sequence (log in, open a page, submit, page again) a rotating proxy user would pay it on every step.

So pick sticky for anything with steps, and rotating for wide independent work where each request should look unrelated to the last. The dashboard generator opens on sticky for that reason; rotating is one click away.

How it works

Add sid and an id you choose. Any request carrying that id reuses the same exit address for as long as the session lives. Add ttl to say how long that may be, in minutes.

USERNAME-sid-checkout42              sticky, default lifetime
USERNAME-sid-checkout42-ttl-30       sticky, up to 30 minutes
USERNAME-cc-de-sid-checkout42-ttl-30 sticky, up to 30 minutes, German exit

• A session id is 1 to 32 letters and digits. Pick something meaningful: checkout42 is easier to find in a log than x.
• Lifetimes run from 1 minute up to the ceiling of your product, listed below, in whole minutes of your choosing.
• A lifetime is an upper bound. Each session runs on a rotation schedule of the width you asked for, so the address is held for up to that long and the first stretch of a brand-new session can be shorter. Write your workflow so a fresh address mid-job is survivable, whatever lifetime you set.
• ttl without sid is an error: there is no session for the lifetime to apply to.
• Change the id and you get a different address immediately, without waiting for anything to expire.

Lifetime ceilings by product

Each product sets its own ceiling. Asking for more than a product allows returns an error rather than a silently shortened session.

Patterns that work

• One session per workflow. Generate an id when a job starts and reuse it for every request in that job, then discard it.
• Set a lifetime that covers the whole job. A session that ends halfway through costs you the setup time again and, worse, changes address mid-flow. A lifetime shorter than the job guarantees that happens; a longer one only makes it less likely, since the lifetime is a ceiling rather than a floor.
• But no longer than the job. The longer you hold one address, the more of its history belongs to you, and the easier your traffic is to recognise as one actor.
• Do not make sessions global. Running every worker under one id funnels all your traffic through one address and looks exactly like what it is.
• Handle the end of a session. When a session rotates, the next request goes out from a fresh address. If your workflow cannot tolerate that, detect it and restart the flow under a new id rather than hoping.

In your code

A sticky request differs from a rotating one by exactly one string. Nothing else about your client changes.

curl -x gate.avocadoproxies.com:8080 \
     -U "USERNAME-sid-a1b2c3-ttl-30:PASSWORD" \
     https://example.com