15% off your first purchase with code WELCOME15, up to 25 GB.

See pricing

Guide · Proxy basics

Rotating vs sticky proxy sessions: when to use each

A rotating proxy gives you a new exit IP on each new connection; a sticky session holds one exit IP for a period you choose. Use rotation for independent requests — one page, one fetch, no state — and a sticky session for anything that spans several requests sharing cookies or a token, such as a search flow, pagination or a checkout. On our gateway the switch is in the username: add _session-<id>_sesstime-<minutes> to hold an IP, leave it out to rotate.

Reviewed 30 Oct 2026

The short answer

  • Rotation is per connection, not per request. A client that keeps a connection alive sends several requests through the same exit.
  • Sticky sessions exist because HTTP state lives in cookies, and many sites expect the cookies and the address to stay together across a flow.
  • One session handle per logical task. A new handle means a new IP; reusing a handle returns the same IP while it holds.
  • On ARC Basic, Fast and Ultra the hold is best effort — the dashboard offers 1 minute to 24 hours — and an exit can drop early. ARC Mobile sessions run 5 to 60 minutes.
  • Design for a changed IP: detect it and restart the flow, rather than treating it as a fatal error.

What rotation and stickiness actually do

A rotating proxy draws an exit from the pool each time your client opens a connection to the gateway. If your HTTP library reuses the connection (keep-alive, HTTP/2 multiplexing), the next request goes out through the same exit. If you want a fresh IP per request, open a new connection per request; if you want a stable one, ask for it explicitly.

A sticky session binds a handle you choose to one exit. Every connection that presents the same handle is routed through the same IP until the session time runs out or the exit goes offline.

Why sessions matter: cookies and state

HTTP is largely stateless; cookies are how servers keep a session across requests (RFC 6265). A search form issues a cookie or a token, the results page expects it back, the detail page expects both. Many sites also notice when that cookie suddenly arrives from a different address and reset or challenge the flow.

Rate limiting works on the same identifiers. RFC 6585, which defines 429 Too Many Requests, notes that a server may identify the user by credentials or a stateful cookie and may count per resource, per server or across servers. So rotation does not make a session-based limit go away — it only changes how per-IP counting sees you.

Which one to use for which job

JobUseWhy
Independent page fetches (catalogue crawl, price checks)RotatingNo state between requests; spreads load across exits
Search → results → detailSticky, ~5–10 minCookies and tokens must travel with one IP
Paginated listingsSticky for the run of pagesSome sites bind pagination cursors to the session
Headless browser task or AI agentSticky for the taskA browser accumulates cookies and storage across many requests
Same address every day for allowlistingNeither — a static IPPool exits are borrowed; see static ISP proxies

How sticky sessions work on our gateway

Targeting on ARC Basic, ARC Fast and ARC Ultra is entirely in the username. A rotating German exit is USERNAME_pool-arcfast_country-de. Add a session handle and a duration and it becomes sticky: USERNAME_pool-arcfast_country-de_session-k3f9a1x2_sesstime-10 holds one IP for ten minutes.

  • _session- takes any handle you choose. The same handle later returns the same exit while the session holds; a new handle draws a new one.
  • _sesstime- is minutes. The dashboard generator offers 1 minute to 24 hours; the API's session_ttl takes 60 to 86,400 seconds. The hold is best effort upstream, with no hard cap.
  • Country and city are part of the string, so a session is tied to its market. Use a different handle per market.
  • ARC Mobile endpoints are generated in the dashboard rather than composed by hand, and their sessions are clamped to 5–60 minutes.

Whatever the duration, an exit can go offline before the time is up. Treat a changed IP as a normal event: detect it, discard the half-finished flow and start it again on a new handle.

Choosing a session length

  • Size it to the task, plus a margin: a fare search flow needs minutes, not hours.
  • Long sessions concentrate traffic on one exit. If a task can be split into independent flows, give each its own handle.
  • For browsers and agents, one session per task — not one per browser process — keeps cookies and IP aligned. See Playwright for wiring a proxy per context.
  • Do not try to keep a pool exit for days. If you need the same address indefinitely, that is a static ISP proxy, not a long sticky session.

Code

Worked example

One handle per task; detect a changed exit and restart
import secretsimport requestsGATEWAY = "proxy.arcproxies.io:8000"PASSWORD = "PASSWORD"def session_proxies(country: str, minutes: int = 10):    handle = secrets.token_hex(4)                      # e.g. k3f9a1x2-style handle    user = f"USERNAME_pool-arcfast_country-{country}_session-{handle}_sesstime-{minutes}"    url = f"http://{user}:{PASSWORD}@{GATEWAY}"    return {"http": url, "https": url}def exit_ip(s: requests.Session) -> str:    return s.get("https://api.ipify.org", timeout=15).textdef run_task(country: str):    with requests.Session() as s:        s.proxies = session_proxies(country)        ip = exit_ip(s)        for step in ("https://example.com/search?q=x", "https://example.com/results"):            s.get(step, timeout=30)            if exit_ip(s) != ip:                           # exit dropped mid-flow                raise RuntimeError("exit changed — restart the task on a new handle")# Rotating: no _session- token; a new connection may draw a new exit.rotating = "http://USERNAME_pool-arcfast_country-de:PASSWORD@proxy.arcproxies.io:8000"# Sticky: the same handle returns the same exit while it holds.sticky = "http://USERNAME_pool-arcfast_country-de_session-k3f9a1x2_sesstime-10:PASSWORD@proxy.arcproxies.io:8000"

FAQ

Questions

Something not covered? Write to contact@arcproxies.io.

What is the difference between rotating and sticky proxies?

A rotating proxy gives you a new exit IP on each new connection. A sticky session holds one exit IP for a duration you choose, so several requests in one task come from the same address. Rotation suits independent fetches; sticky sessions suit multi-step flows.

Does a rotating proxy change IP on every request?

It changes on every new connection. If your HTTP client keeps the connection alive or multiplexes requests over HTTP/2, consecutive requests can share one exit. Open a new connection per request if you need a fresh IP each time.

How long can a sticky session last?

On ARC Basic, Fast and Ultra you set the minutes in _sesstime-; the dashboard offers 1 minute to 24 hours and the API accepts 60 to 86,400 seconds. The hold is best effort and an exit can drop early. ARC Mobile sessions run 5 to 60 minutes.

When should I use a sticky session?

Whenever several requests must share state: a search followed by results and a detail page, paginated listings, a logged-out checkout preview, or a headless browser or AI agent task. HTTP state lives in cookies, and many sites expect cookies and address to stay together.

What happens if a sticky IP goes offline?

The session moves to a different exit. Build for it: check the exit IP during the flow, and if it changes, discard the partial result and restart the task on a new session handle.

How do I get a new IP in a sticky setup?

Use a new session handle. Each distinct value after _session- draws its own exit; reusing a handle returns the same exit while the session holds.

Sources & review

Last reviewed by the ARC Proxies team. Prices are read from the live catalog at build time.

  1. [1]IETF: RFC 6265: HTTP State Management Mechanism
  2. [2]IETF: RFC 6585: Additional HTTP Status Codes (429 Too Many Requests)
  3. [3]IETF: RFC 9110: HTTP Semantics

Next

Where to go from here

Use caseProxies for web scraping and data collectionA second provider that just works — Scrapy, requests, Crawlee or Playwright, self-serve, no sales call, bandwidth that never expires.Use caseResidential proxies for AI agentsBring your own residential IPs to browser-use, Playwright, Crawl4AI, n8n and any MCP tool — one sticky session per task, billed per GB.GlossarySticky sessionA sticky session is a setting on a rotating proxy that keeps the same exit IP address for a chosen period, usually by attaching a session identifier to the connection, so a multi-step task appears to come from one address from start to finish.GlossaryRotating proxyA rotating proxy is a proxy endpoint that automatically assigns a different exit IP address from a pool to new connections or requests, so one client's traffic is spread across many addresses without the client managing a list.GlossaryBackconnect proxyA backconnect proxy is a single gateway address that a client connects to while the gateway forwards each connection out through one of many exit IPs behind it, so the client configures one host, port and set of credentials instead of a list of proxies.ProductResidentialReal consumer IPs in 185+ countries with city targeting, rotating or sticky, billed per gigabyte with no subscription and no expiry.ProductStatic IPsDedicated addresses that stay yours, priced per IP per month with unmetered traffic — when a target needs to see the same IP every time.IntegrationPlaywrightSet up an authenticated proxy in Playwright for Python and Node: launch and per-context proxies, sticky sessions, geo-targeting and handling proxy errors.IntegrationPython requestsUse an authenticated proxy with Python requests: the proxies argument, sticky sessions per task, geo-targeting, SOCKS5 and retries that skip 407 errors.