Every proxy request answers one quiet question: should this look like the same visitor as the last one? Get it wrong in one direction and your login flow breaks halfway through checkout. Get it wrong in the other and you burn a single IP until the target blocks it.
Sessions are how you answer that question on purpose.
#Two modes
Rotating sessions give every request a fresh exit. Nothing ties one request to the next, which is exactly what you want for collecting public pages at volume — no single IP accumulates enough traffic to look unusual.
Sticky sessions pin a series of requests to one exit for a set time. To the target, it's one visitor clicking around: the same IP that logged in is the one that adds to the cart and checks out.
#How a sticky session works on RiftIP
You create a session by adding an ID to your username. Any requests that carry the same ID share an exit until the session's time-to-live runs out.
curl -x "http://acme-net-residential-session-checkout42-ttl-30m:PASSWORD@gate.riftip.com:7777" \
https://shop.example.com/accountimport requests
proxy = "http://acme-net-residential-session-checkout42-ttl-30m:PASSWORD@gate.riftip.com:7777"
s = requests.Session()
s.proxies = {"http": proxy, "https": proxy}
s.post("https://shop.example.com/login", data={"email": "...", "password": "..."})
s.get("https://shop.example.com/cart") # same exit, same visitorimport { ProxyAgent, fetch } from "undici";
const agent = new ProxyAgent("http://acme-net-residential-session-checkout42-ttl-30m:PASSWORD@gate.riftip.com:7777");
await fetch("https://shop.example.com/cart", { dispatcher: agent });The session ID is yours to choose. Use something that maps to your own unit of work — an account, a cart, a crawl job — so that retries naturally reuse the right identity.
#How long should a session live?
Long enough for the flow, and no longer. A session that outlives its job just concentrates traffic on one IP.
| Flow | Suggested TTL |
|---|---|
| Search, then open a result | 2–5 minutes |
| Login and a few account pages | 10–30 minutes |
| Checkout or multi-step forms | 30–60 minutes |
| Long-lived account monitoring | Use ISP proxies instead |
Residential and Unlimited Residential sessions can last up to 24 hours; mobile sessions up to 30 minutes, because carriers reassign IPs on their own schedule. ISP and datacenter IPs never change, so they're "sticky" by nature.
#What happens when an exit drops
Residential exits are real devices, and real devices go offline. When that happens mid-session, the gateway re-pins your session to a fresh exit — in the same city and ISP where possible — and the next request goes through it. Your session ID doesn't change, so neither does anything you keyed on it.
Note
Re-pinning keeps your flow alive, but the target will see a new IP. Most sites accept that — home connections change IPs all the time — but if a target binds a login to an exact IP, use ISP proxies for that flow.
#Patterns that work
- One session per account. If you manage many accounts, give each its own session ID so they never share an exit.
- Rotate between jobs, stick within them. A crawl job can rotate across pages but stick while it walks a paginated list.
- Retry with the same ID. When a request fails, retrying with the same session ID keeps the identity consistent; switching IDs mid-flow is what usually triggers a re-login.
Sessions are a small parameter with an outsized effect on success rate. Treat the session ID as part of your data model, not an afterthought, and most "random" login failures simply go away.
Get the next post by email
One short email when a new guide ships — scraping, SERP and proxy engineering. No noise, unsubscribe any time.