Sticky proxy sessions: rotation and duration

Short answers

A sticky session keeps the same device; the carrier may still change the IP. Choose the mode around the work you need to complete, then test that work with its actual client.

Choose between connection rotation, timed rotation and sticky sessions

Per-connection rotation does not mean a new address for every HTTP request. A client can reuse a connection for several requests. Connection reuse is a normal HTTP-client behaviour; curl explains it in its connection reuse documentation.

Timed rotation is a routing setting, not a guarantee that an existing connection will change address at an exact instant. Test the boundaries your job depends on.

Keep one name for one job

A session name accepts one to 64 lower-case letters, digits or underscores. Keep it for the related requests in one job. Do not generate a new name inside the loop that sends each request.

The example below creates configuration only. It sends no request and contains no credential. Create it once when the job starts, then use the same settings in the connection builder API:

from uuid import uuid4

session_name = "qa_" + uuid4().hex
connection_settings = {
    "pool": "residential",
    "country": "any",
    "rotation": "sticky",
    "session": session_name,
    "protocol": "http",
}

country: "any" is illustrative. Select the country your job requires and check its current availability. The setup documentation explains the connection fields.

When the public API receives sticky mode without a session name, it derives a stable name for the account credential. That fallback is convenient, but explicit names make separate jobs easier to track. A session name is visible in the proxy username: never put a password, email address or customer identifier in it.

What the ttl setting means

For an advanced username configuration, ttl-900 requests a lifetime of 900 seconds, or 15 minutes. The documented lifetime is fixed for a live session name; changing the number on that name is not a supported way to extend it. Start a new name when you need a separately configured session.

The public POST /v1/traffic/build-url request has no ttl field. Do not add one to its JSON or assume that a generated URL has a particular lifetime. If duration is essential to your job, confirm the intended configuration before starting a long run. See username settings.

Separate session lifetime, device availability and IP continuity

These are three different things:

• Session lifetime: how long the configured session is intended to remain usable.
• Device availability: whether the selected device can still carry traffic.
• IP continuity: whether the network keeps the same public address on that device.

A longer lifetime cannot keep an offline device connected or prevent its network from changing the address. Portproof traffic uses shared pools. Check whether your workflow requires a continuing application session, the same exit device or an unchanged IP; those requirements need different tests.

Browser cookies are separate again. Changing an exit does not automatically delete them. The destination application decides whether its session remains valid. How HTTP cookies work.

Decide what to do when a session stops working

Keep the last completed step and the error, then stop before repeating a write. For a read-only check, a limited retry with a delay may be appropriate. For a purchase or form submission, confirm whether it completed before trying again; follow the application’s idempotency rules. HTTP retry semantics.

If you need to begin again on another session, restart from a known application state. Do not clear all cookies merely because the address changed. In Python, a Requests Session maintains its own cookie state and connection pool independently of the proxy session name. Requests Session behaviour.

Use sticky-session troubleshooting to investigate a changed address and CONNECT troubleshooting for tunnel failures.

Match the session boundary to the task

A sticky session does not set request pacing. Respect the destination’s permitted access and rate limits in every mode.

Measure the traffic your job actually uses

Rotation settings alone do not predict bandwidth. Payload size, browser assets, connection reuse and retries all affect the work performed. Measure a small representative run before estimating a larger one.

Use the traffic accounting guide to understand the usage counter and the GB planning guide to size an order. Current traffic rates are on pricing.

Check these before starting a long run

1. Keep the complete pool, country, rotation and session settings consistent through the job.
2. Give independent jobs deliberate session names rather than sharing one by accident.
3. Confirm any lifetime requirement instead of treating the largest accepted ttl as an availability promise.
4. Keep credentials out of logs. Record a non-sensitive job label, timestamps and error codes.
5. Test recovery at an application boundary you can safely restart.

If an unchanged IP is essential, detect changes and pause the affected job. That check measures your requirement; it does not identify which device the network used.

What is not allowed

Use sessions for permitted work such as QA, ad verification and market research. Follow the acceptable-use policy.

Read next