PacketStream sticky sessions & country targeting, in detail

02 How rotation works

Without a session modifier, PacketStream selects an available residential exit whenever your application opens a new proxy connection. All requests sent over that connection use the same exit. This is connection-based rotation, not per-request rotation, and it has two practical consequences:

• Your HTTP client decides how often you rotate. Browsers and HTTP libraries pool and reuse connections, so a refresh, a new page or a new request may or may not open a new connection. Ten requests can come from one IP or from ten.
• A new connection is a new selection, not a guaranteed new IP. The docs are explicit: “The contract is exit selection for each new connection, not uniqueness across a sample.”

The credentials for automatic rotation are just the plain username and auth key:

Username: USERNAME
Password: AUTH_KEY

To observe it, run separate curl processes — each one opens 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

If you need a fresh IP per request, force a new connection per request (disable keep-alive or create a new client), and de-duplicate on your side if uniqueness matters. Automatic rotation suits independent public-page checks where consecutive requests do not need the same identity.

03 Sticky sessions

Append _session- and a workflow label to the auth key. New proxy connections that carry the same label are kept on the same residential exit. Sticky sessions are available to all customers at no extra cost.

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}'

• One label per related workflow — a login, a cart, a multi-page form.
• Separate labels for concurrent workflows; two workers sharing a label share an IP.
• Non-sensitive labels only. Do not put email addresses, customer IDs, destination credentials or other personal data in a session ID.

04 The rolling 60-minute timeout

The 60-minute figure is an inactivity timeout, and it is rolling — “not a fixed maximum session lifetime”. The precise rules:

1. Each time PacketStream assigns the session to a new proxy connection, the 60-minute timer restarts.
2. Requests sent over an already-open connection do not restart the timer, because no exit selection is needed. That connection keeps its exit even if the stored session mapping expires.
3. After 60 minutes without a new connection assignment, the mapping expires.
4. The next new connection using the same label starts a new session and may receive a different exit.

So a session that opens at least one new connection every 60 minutes can stay on one exit for longer than an hour — as long as the sharer behind it stays online.

05 When a session fails

A sticky session depends on the Packeter (the sharer) providing its exit. If that person’s device disconnects, the session fails; PacketStream does not silently switch it to a different identity. For logged-in or stateful work that is the safer behaviour — an unannounced IP change halfway through a session is the kind of signal sites’ fraud checks look for. The docs recommend designing recovery around the whole workflow:

1. stop the failed workflow;
2. discard state that cannot safely continue with a new identity (cookies, carts, CSRF tokens);
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 label in a tight retry loop.

06 Country targeting

Append _country- and an ISO two-letter code. The docs ask for uppercase codes in new integrations; the host and port do not change.

COUNTRY_PASSWORD="${PACKETSTREAM_AUTH_KEY}_country-US"

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

For a country-sensitive workflow, verify the returned country before collecting the intended destination. The easiest way to get a valid code is to choose the country in the Location list on the dashboard’s Proxy Access page, which generates the password with the right suffix.

The city or region an IP database reports for a country-targeted exit is approximate diagnostic data. For localisation work, the docs point out that the exit country is one signal among several: sites also read browser locale and accepted languages, cookies and prior session state, account settings, regional hostnames, and delivery or billing details, so set those to match the target market.

07 Unavailable and unrecognised countries

Two cases behave differently, and both are easy to handle:

The docs recommend keeping failure types distinct in your application:

requested country unavailable → record unavailable work
authentication failed          → stop and fix credentials
destination failed             → apply the destination retry policy

Do not remove the country constraint inside a generic retry handler — that “can turn a visible availability failure into plausible data from the wrong market”. Retry availability with bounded backoff and give the job a total time limit.

08 Country + session together

Both modifiers go on the auth key, country first:

AUTH_KEY_country-DE_session-market42

The country rule still applies: if no exit is available in the selected country, the request fails instead of falling back to another location. And the sticky-session contract is unchanged: the exit can be retained across new connections within the rolling 60-minute window, and the session fails if its sharer disconnects.

09 Verify and record the exit

Record the requested country alongside every result, as job configuration, rather than inferring it later from a URL or an IP database. The docs suggest a minimal provenance record:

{
  "requested_country": "US",
  "observed_country": "US",
  "collected_at": "2026-07-22T14:05:00Z",
  "source_url": "https://example.com/public-page"
}

Keep proxy credentials and auth-key modifiers containing labels out of stored provenance. Comparing requested_country with observed_country catches the unrecognised-code problem above.

10 Choosing the right mode

In all four cases your application remains responsible for concurrency, timeouts, retries and connection-pool configuration — which, given connection-based rotation, effectively controls your rotation rate.

• Setup guide Client code for seven tools
• Full review Ratings and verdict
• FAQ Common questions answered