PacketStream documentation

Rotation and sticky sessions

Understand PacketStream's connection-based rotation and use sticky sessions to keep one residential exit for a related workflow.

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 assigns the session to a new proxy connection, the timeout restarts. A session that opens at least one new connection during every 60-minute window can therefore remain on the same exit for longer than one hour.

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 new connection assignment, 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. If that Packeter disconnects, the session fails. PacketStream does not silently switch the session to a different identity.

Design recovery around 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 reuse a failed session indefinitely in a tight retry 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

WorkloadStarting point
Independent public-page checksAutomatic rotation
Several steps that must share one exitSticky session
Location-sensitive independent checksCountry targeting with automatic rotation
Location-sensitive multi-step workflowCountry targeting with a sticky session

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

Questions? We’re here to help. Talk with our support team about your integration.
Contact support