Guide · 5 min read · 2026-10-06

Sessions and rotation: when to hold an address

How to decide between a rotating and a sticky session, and how to design a job that survives an address changing.

Rotation and stickiness are controls over how long one exit address represents you. The exact way to request each is shown in your dashboard for the product you bought; this guide covers the decision, not the syntax.

Rotate when requests are independent

A crawl of many unrelated pages has no reason to look like one visitor. Rotating spreads load so that no single address attracts a rate limit, and a failed address costs you one request.

Hold an address when a flow has state

Logging in, paging through results that depend on a cursor, adding to a basket and checkout all expect the same visitor across several requests. A sticky session keeps the address for a period. Plans differ in how long, so read the limit before you design a flow that needs ten minutes.

Design for the address changing anyway

  • Make each step idempotent where you can, so a repeated request does no harm.
  • Detect a lost session by checking for a login page or a changed cookie, not by status code.
  • Keep cookies per session and discard them with it. Reusing a cookie jar across addresses ties unrelated addresses together.
  • For flows that must hold one address for days, a static ISP proxy is the better fit than a sticky residential session.
python: one client per session, discarded with it
import requests

def new_session(proxy_url: str) -> requests.Session:
    s = requests.Session()
    s.proxies = {"http": proxy_url, "https": proxy_url}
    return s

session = new_session(PROXY_URL)
try:
    session.get("https://example.com/login", timeout=30)
finally:
    session.close()

More guides

Test it on your own targets.

Create an account, run the measurement harness against your real workload, and read the numbers before you commit to anything.