Sticky Sessions vs Per-Request Rotation: Choosing the Right Mode

The single most common configuration mistake we see is a customer running a login flow through per-request rotation, concluding the proxies are "unstable", and buying a larger pool that makes it worse.

Rotation is not a dial from worse to better. It is a statement about what the target should believe. Per-request rotation says "many unrelated visitors". A sticky session says "one visitor, doing a sequence of things". Pick the one that matches reality for that flow.

The decision

The pattern is simple: state on the target implies stickiness on your side. If the origin is maintaining anything about you between requests, your address should not change beneath it.

How sticky sessions work here

A session is a segment in the proxy username. The same string maps to the same exit IP for as long as the lease holds; a different string gets a different address. There is no separate API call and no connection to keep open.

# Two independent journeys, two exit IPs, same credential
curl -x http://user-country-us-session-7f2a91c40b3e:[email protected]:8080 \
  -s https://api.fleetproxy.com/v1/ip

curl -x http://user-country-us-session-c40b3e7f2a91:[email protected]:8080 \
  -s https://api.fleetproxy.com/v1/ip

Because the session lives in the credential string, it composes with targeting. user-country-gb-city-london-session-abc123def456 is a London address held for the session. Omit the session segment entirely and you get per-request rotation.

Leases last up to 30 minutes of activity and are released after roughly 10 minutes of silence. Neither is a guarantee: the underlying peer can leave the network at any moment, which is inherent to residential inventory rather than a policy choice. Treat the session as best-effort and write code that notices when the address changed.

import httpx

class StickySession:
    """Wraps one journey and detects when the underlying exit IP has moved."""

    def __init__(self, session_id: str, country: str = "us") -> None:
        proxy = (
            f"http://user-country-{country}-session-{session_id}"
            f":[email protected]:8080"
        )
        self._client = httpx.Client(proxy=proxy, timeout=30.0, follow_redirects=True)
        self._ip: str | None = None

    def get(self, url: str) -> httpx.Response:
        response = self._client.get(url)
        current = response.headers.get("x-fleet-exit-ip")
        if self._ip is None:
            self._ip = current
        elif current and current != self._ip:
            raise ConnectionError(f"exit IP moved {self._ip} -> {current}; restart journey")
        return response

    def close(self) -> None:
        self._client.close()

Raising is deliberate. Silently continuing after the address moved produces a half-authenticated session that returns plausible-looking wrong data — the worst failure mode available.

Failure modes of each

Per-request rotation, used where state exists. Symptoms: random logouts, carts emptying, CSRF token mismatches, pagination that restarts at page one, challenge pages that appear only on longer runs. Every one of these gets misdiagnosed as flaky proxies.

Sticky sessions, held too long. One session used for a hundred thousand requests is one IP doing a hundred thousand requests. You have reinvented the single-address problem with extra steps. One session per logical journey, then discard.

Too many sessions at once. Two hundred concurrent sticky sessions on one target from one account is a visible cluster even though every address differs. Concurrency budgets still apply.

Session reuse across identities. Two accounts sharing one session string are two accounts sharing one IP. If the point of the session was isolation, that single line of code undoes it.

Choosing session length

Match the session's life to the journey's, not to the lease's maximum:

• Login plus a handful of authenticated reads: one session, closed at logout.
• Search plus pagination: one session for the result set, discarded when you move to an unrelated query.
• Long-running account presence: not a sticky session at all — use a static residential IP, which does not expire.

Static residential exists for exactly the case where 30 minutes is nowhere near long enough. If a profile needs the same address next Tuesday, a rotating pool with sticky sessions is the wrong product.

The rule worth memorising

Ask what the origin thinks it is looking at. If it thinks it is looking at one person doing one task, hold the address. If it does not know or care that a previous request happened, rotate freely. Almost every rotation question answers itself once phrased that way.