Rotation and sticky sessions

PacketStream supports automatic rotation and sticky sessions for all direct proxy customers. Choose behavior based on the unit of work—not on an assumed one-request-per-IP model.

Automatic rotation

Without a sticky-session modifier, PacketStream automatically selects an available residential exit whenever your browser or application opens a new proxy connection.

Username: USERNAME
Password: AUTH_KEY

Browsers and HTTP libraries manage these connections behind the scenes. A refresh, new page, or new request may reuse an existing connection or open a new one. That means it may continue through the same exit or trigger another selection—even while the browser or application stays open.

Multiple requests sent over the same connection use the same exit. A new connection triggers a new selection, but the selected IP is not guaranteed to be different from the previous one.

Automatic rotation is a good fit when consecutive requests do not need to keep the same identity. Use a sticky session when a login, cart, or other multi-step workflow must remain on one exit.

Observe new connections with cURL

Each iteration below starts a separate cURL process and therefore establishes its own proxy connection:

for attempt in 1 2 3 4 5; do
  curl --silent --show-error --fail-with-body \
    --proxy 'https://proxy.packetstream.io:31111' \
    --proxy-user "${PACKETSTREAM_USER}:${PACKETSTREAM_AUTH_KEY}" \
    'https://ipinfo.io' \
    | jq -r '[.ip, .country, .org] | @tsv'
done

A small sample is not guaranteed to contain a different IP on every line. The contract is exit selection for each new connection, not uniqueness across a sample.

Sticky sessions

Append _session- and a workflow label to the auth key:

AUTH_KEY_session-catalog42

The session label keeps new proxy connections on the same residential exit. Sticky sessions are available to all customers.

SESSION_PASSWORD="${PACKETSTREAM_AUTH_KEY}_session-catalog42"

curl --silent --show-error --fail-with-body \
  --proxy 'https://proxy.packetstream.io:31111' \
  --proxy-user "${PACKETSTREAM_USER}:${SESSION_PASSWORD}" \
  'https://ipinfo.io' \
  | jq '{ip, country, org}'

Use one session label for one related workflow. Separate concurrent workflows should use separate labels.

60-minute inactivity timeout

The 60-minute timeout is rolling, not a fixed maximum session lifetime. Each time PacketStream serves a new proxy connection on the label, the timeout restarts. There is no maximum lifetime: a label keeps the same exit for as long as it opens at least one successful new connection in every 60-minute window.

Failed connections do not restart the timeout.

Requests sent over an already-open proxy connection do not restart the timeout because they do not require another exit selection. That connection continues through its selected exit even if the stored session mapping expires.

After 60 minutes without a successful new connection, the session mapping expires. The next new connection using the same label starts a new session and may receive a different exit.

Session failure behavior

A sticky session depends on the Packeter providing its exit. PacketStream never moves a session label to a different IP. If that Packeter disconnects, new connections on the label fail until one of these happens:

• the same IP comes back online, and the label continues on it;
• 60 minutes pass without a successful connection, and the label expires. The next connection with that label gets a new IP.

While the label’s IP is offline, PacketStream returns:

A short busy period on the exit can also return the selected relay is offline or busy processing other threads.

If your workflow can wait for the same IP, retry with backoff and a limit on attempts and total time.

If it cannot wait, recover the whole stateful workflow:

1. stop the failed workflow;
2. discard state that cannot safely continue with a new identity;
3. select a new session label;
4. restart from a known checkpoint;
5. keep the retry count and total recovery time bounded.

Do not retry a failed session label in a tight loop.

Combine a country and session

Place both modifiers on the auth key when a workflow needs country targeting and continuity:

AUTH_KEY_country-US_session-catalog42

The country rule still applies. If no exit is available in the selected country, the request fails instead of falling back to another location.

Choose the right behavior

The application remains responsible for its own concurrency, timeouts, retries, and connection-pool configuration.