Rotating vs Sticky Sessions

Rotating sessions solve per-IP rate limiting: by assigning a new IP to each request, the workload distributes its request volume across the pool and keeps per-IP request rates below any threshold the target enforces. Sticky sessions solve IP-bound session continuity: by pinning the same IP for a workflow's duration, the workload presents consistent origin signals to targets that associate session state with the requesting IP.

These two problems cannot both be solved by the same configuration. Rotation prevents rate limiting by maximizing IP diversity — which breaks session continuity. Sticky sessions preserve session continuity by minimizing IP diversity — which concentrates requests on fewer IPs and reintroduces rate limiting within the session window. The choice is not a performance trade-off; it is a selection based on which problem the workload has.

Rotating configuration: the client connects to the provider's gateway endpoint without a session ID in its credentials. The gateway assigns a new exit IP for each new connection. For HTTP/1.1, each request creates a new connection and receives a new IP. For HTTP/2 with connection multiplexing, multiple requests may share one connection and therefore one exit IP until the connection closes. Clients that need strict per-request rotation must disable connection keepalive or force connection closure between requests.

Sticky configuration: the client includes a session identifier in the proxy credentials — typically appended to the username in the format `user-session-{id}`. The gateway pins all requests from that session ID to the same exit IP for the configured duration. The session ID can be any consistent string; using the same ID across all requests in a workflow maintains IP consistency. Using a new ID starts a new session with a new IP assignment.

Hybrid approach for workloads with both requirements: use rotating configuration between workflow executions, and sticky configuration within each execution. Each scraping job starts with a new session ID — getting a fresh IP — and maintains that IP through the job's completion. The next job uses a new session ID. This maximizes IP diversity across jobs while maintaining continuity within them. The session duration must be set to exceed the longest expected job completion time.

Targets that don't bind session state to IP — session cookies validated independently of origin — work correctly with either configuration. Rotating proxies don't break these sessions because the session token carries the state regardless of IP. Sticky sessions add no benefit but also add no harm. For these targets, rotating is the better default because it distributes requests across more IPs and provides greater resilience against per-IP reputation accumulation.

Targets that bind session state to IP — where the session cookie or authentication token is issued to the requesting IP and validated against subsequent requests' origin — fail under rotating configuration. The login request succeeds; the next request from a different IP is treated as a new, unauthenticated session. Sticky sessions are required. The session duration must exceed the time from login to session completion, or the IP change from sticky session expiry breaks authentication mid-workflow.

Targets with per-IP rate limits and IP-bound sessions simultaneously require a configuration that balances both constraints. Sticky sessions within a rate-limit-aware execution: set the sticky window to the minimum needed for one workflow execution, run concurrent workflows on separate session IDs (separate IPs), and size the concurrent session count such that no individual IP receives more than the rate limit allows within the window.

Rotating on an IP-bound session target: the workflow completes step 1 successfully and fails at step 2 with a redirect to login or an authentication error. This happens consistently at the same step — the step where the target checks the session against the origin IP. The failure pattern repeats identically across all attempts. This looks like a proxy reliability issue but is a configuration mismatch. The proxy delivered a valid IP; the configuration changed the IP between steps the target expected to see the same origin.

Sticky on a rate-limited target at high concurrency: block rate increases with request volume even though IP rotation appears to be configured. Sticky sessions concentrate requests from each workflow execution on a single IP. At high concurrency, multiple workflows sharing IPs from a thin session pool hit per-IP rate limits. The sticky configuration that was meant to maintain session continuity is creating the per-IP concentration it was supposed to avoid in the concurrent case.

Sticky session expiry mid-workflow: the workflow fails at an unpredictable point — not at a consistent step, but at varying depths into the execution. The failure correlates with elapsed time since session start rather than with specific workflow steps. The proxy session expired and assigned a new IP; the target's session validation failed on the new IP. The fix is extending the sticky session duration, not debugging the scraping logic.

Short sticky windows — 1 to 5 minutes — minimize the rate limiting window within each session. Each session accumulates fewer requests before the IP rotates. This is appropriate for short workflows where the session completes before the window expires. The cost is that long workflows break at the rotation point — mid-execution IP changes cause session failures on IP-bound targets.

Long sticky windows — 10 to 30 minutes — support longer workflows without mid-execution IP changes. The cost is per-IP request concentration: all requests in the window come from the same IP, which is subject to per-IP rate limiting for the full duration. For high-volume scraping within a session, long sticky windows recreate the rate limiting problem that rotation was meant to solve.

The correct sticky duration is the minimum that covers the maximum workflow execution time plus buffer for variability. Setting sticky duration to the provider's maximum available is not safer — it maximizes per-IP request concentration for no operational benefit. Setting it to the minimum needed for the workflow minimizes both the rate limiting window and the risk that session expiry interrupts the workflow.