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:
- stop the failed workflow;
- discard state that cannot safely continue with a new identity;
- select a new session label;
- restart from a known checkpoint;
- 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
| Workload | Starting point |
|---|---|
| Independent public-page checks | Automatic rotation |
| Several steps that must share one exit | Sticky session |
| Location-sensitive independent checks | Country targeting with automatic rotation |
| Location-sensitive multi-step workflow | Country targeting with a sticky session |
The application remains responsible for its own concurrency, timeouts, retries, and connection-pool configuration.