Sticky Sessions & Manual Rotation
What Are Sticky Sessions?
When you use the proxy rotator normally, each request may exit through a different proxy IP. This is called rotation - your traffic appears to come from different locations.
Sticky sessions let you "stick" to the same exit IP across multiple requests for the configured route. Think of it like reserving a specific proxy just for your session.
Normal rotation (default): Request 1 -> Proxy A -> Exit IP: 1.2.3.4 Request 2 -> Proxy C -> Exit IP: 5.6.7.8 Request 3 -> Proxy B -> Exit IP: 9.10.11.12 With sticky session: Request 1 -> Proxy A -> Exit IP: 1.2.3.4 Request 2 -> Proxy A -> Exit IP: 1.2.3.4 <- same IP Request 3 -> Proxy A -> Exit IP: 1.2.3.4 <- same IP
When Do You Need Sticky Sessions?
- Login sessions - Websites that check if your IP changes mid-session
- Multi-step workflows - Shopping carts, form submissions, checkout flows
- API rate limits - When you need consistent identity for rate limit tracking
- Scraping sequences - When you need to maintain state across page navigations
Sticky Sessions Across Multiple Domains
Standard sticky sessions keep the same exit for the configured route that handles the requested domain. They do not automatically override routing for every other domain a browser loads.
Standard sticky session: main-site.example -> Exit IP: 1.2.3.4 cdn.example -> Exit IP: 1.2.3.4 fonts.googleapis.com -> Exit IP: 5.6.7.8 (possible if routed differently) With cross-domain exit coherence enabled: First pin-eligible request -> Exit IP: 1.2.3.4 Main site, CDN, captcha, analytics -> Exit IP: 1.2.3.4
Need one IP across a full browser workflow? Ask support to confirm that cross-domain exit coherence is enabled for your proxy endpoint and target workflow.
Use separate session IDs per workflow and geography. When cross-domain coherence is enabled, the first pin-eligible request for a session controls the exit used by later domains. If you first use a session on a UK target and then reuse the same session ID for an Italy target, the Italy request may keep the earlier UK exit. Use IDs like task-uk-1 and task-it-1.
How to Use Sticky Sessions
For Username/Password Authentication
Simply add -session- followed by any identifier to your username:
# Format: username-session-YOURID:password # Example: Create a session called "mysession" curl -x "john-session-mysession:password123@cld-us-xxxx.tp-ns.com:80" https://checkip.amazonaws.com # Every request with "john-session-mysession" uses the same exit IP for that route curl -x "john-session-mysession:password123@cld-us-xxxx.tp-ns.com:80" https://checkip.amazonaws.com curl -x "john-session-mysession:password123@cld-us-xxxx.tp-ns.com:80" https://checkip.amazonaws.com
Session ID limits: The session ID (the part after -session-) can be any string up to 64 characters. Longer values are ignored and your request will fall back to normal rotation, so keep IDs short. UUIDs (36 chars), short task names, or numeric counters all work well.
For IP-Based Authentication (Hybrid Auth Mode)
If you use IP-based authentication (no username/password required), you can still get sticky sessions using Hybrid Auth Mode - send a session ID in the username with an empty password:
# Format: -session-YOURID: # Note the colon with nothing after it (empty password) # Example with curl's -U flag curl -U "-session-mysession:" -x "cld-us-xxxx.tp-ns.com:80" https://checkip.amazonaws.com # Or with the full proxy URL format curl -x "http://-session-mysession:@cld-us-xxxx.tp-ns.com:80" https://checkip.amazonaws.com
How it works:
- Your IP is still used for authentication (must be whitelisted)
- The session ID is extracted from the username
- The empty password tells the proxy to skip password verification
This works for both HTTP and HTTPS requests.
What Is Manual Rotation?
Manual rotation means you control when to get a new IP, rather than getting a random one each request.
With sticky sessions, you keep the same IP until you decide to change it. To rotate (get a new IP), simply use a different session ID:
# Session "v1" - assigned to Proxy A (1.2.3.4) curl -x "john-session-task1-v1:pass@cld-us-xxxx.tp-ns.com:80" https://checkip.amazonaws.com # Output: 1.2.3.4 # Still using "v1" - same IP curl -x "john-session-task1-v1:pass@cld-us-xxxx.tp-ns.com:80" https://checkip.amazonaws.com # Output: 1.2.3.4 # NOW ROTATE: Switch to "v2" - gets assigned to different proxy curl -x "john-session-task1-v2:pass@cld-us-xxxx.tp-ns.com:80" https://checkip.amazonaws.com # Output: 5.6.7.8 <- new IP!
Key insight: The session ID is just a string you control. Change the string, get a new IP assignment.
Cross-domain workflows: changing the session ID also creates a new cross-domain pin where that feature is enabled. Keep one session ID for one browser journey, target site, and geography.
Session Expiration
Sessions automatically expire after 24 hours of inactivity.
- Inactivity means no requests using that session ID
- Each request resets the 24-hour timer
- Active sessions do not expire from inactivity while requests continue, but endpoint safety limits still apply
10:00 - Create session "mysession" (expires tomorrow at 10:00) 14:00 - Make a request (timer resets, now expires tomorrow at 14:00) 14:01 - Make another request (timer resets again) ... If you stop making requests for 24 hours -> session expires
Provider-backed routes: some residential proxy providers also enforce their own sticky-session lifetimes. Your proxy session ID may remain valid for 24 hours of inactivity, but the upstream residential exit may have a shorter provider-side lifetime depending on your endpoint configuration. Ask support if you need long-lived residential IP stickiness.
Keeping Sessions Alive
If you need a session to last longer than 24 hours, just make periodic requests:
# Simple keepalive - run every few hours curl -x "john-session-mysession:pass@cld-us-xxxx.tp-ns.com:80" -s https://checkip.amazonaws.com > /dev/null
Quick Reference
| Task | How to Do It |
|---|---|
| Create a sticky session | Add -session-YOURID to username |
| Keep the same IP | Use the same session ID |
| Get a new IP (rotate) | Use a different session ID |
| Keep session alive | Make requests within 24 hours |
| IP auth with session | Use -session-YOURID: (empty password) |
| Use many session IDs | Supported for normal workflows; contact support for thousands of active sessions |
| Use one IP across main site + CDN/captcha/analytics | Ask support to confirm cross-domain exit coherence |
| Run different country workflows | Use separate session IDs per country or workflow |
Examples
Python
import requests # With username/password authentication PROXY = "http://john-session-mysession:password123@cld-us-xxxx.tp-ns.com:80" # All requests use the same exit IP for that route for i in range(5): response = requests.get("https://checkip.amazonaws.com", proxies={"http": PROXY, "https": PROXY}) print(f"Request {i+1}: {response.text.strip()}")
With IP-based authentication (Hybrid Auth Mode):
import requests # IP auth with session ID - note the empty password after the colon PROXY = "http://-session-mysession:@cld-us-xxxx.tp-ns.com:80" for i in range(5): response = requests.get("https://checkip.amazonaws.com", proxies={"http": PROXY, "https": PROXY}) print(f"Request {i+1}: {response.text.strip()}")
Node.js
const axios = require("axios"); const HttpsProxyAgent = require("https-proxy-agent"); // With username/password authentication const agent = new HttpsProxyAgent( "http://john-session-mysession:password123@cld-us-xxxx.tp-ns.com:80" ); // All requests use the same exit IP for that route for (let i = 0; i < 5; i++) { const response = await axios.get("https://checkip.amazonaws.com", { httpsAgent: agent, }); console.log(`Request ${i + 1}: ${response.data.trim()}`); }
With IP-based authentication (Hybrid Auth Mode):
const axios = require("axios"); const HttpsProxyAgent = require("https-proxy-agent"); // IP auth with session ID - note the empty password (nothing after colon) const agent = new HttpsProxyAgent( "http://-session-mysession:@cld-us-xxxx.tp-ns.com:80" ); for (let i = 0; i < 5; i++) { const response = await axios.get("https://checkip.amazonaws.com", { httpsAgent: agent, }); console.log(`Request ${i + 1}: ${response.data.trim()}`); }
Manual Rotation Example
import requests def get_proxy(session_id): return f"http://john-session-{session_id}:password123@cld-us-xxxx.tp-ns.com:80" # Use session v1 proxy_v1 = get_proxy("task-v1") print(requests.get("https://checkip.amazonaws.com", proxies={"http": proxy_v1, "https": proxy_v1}).text.strip()) # Output: 1.2.3.4 # Rotate to v2 when needed proxy_v2 = get_proxy("task-v2") print(requests.get("https://checkip.amazonaws.com", proxies={"http": proxy_v2, "https": proxy_v2}).text.strip()) # Output: 5.6.7.8
Common Questions
Q: How many sticky sessions can I have?
A: You can create many session IDs, but they are not literally unlimited. Active sessions are subject to endpoint safety limits and abandoned sessions are cleaned up after 24 hours of inactivity. Normal per-task, per-browser, or per-workflow session usage is fine. If you expect thousands of active session IDs, or if your system creates a new session ID for every request, contact support so we can confirm the right limits for your endpoint.
Q: What if my assigned proxy goes down?
A: For standard sticky sessions, the proxy rotator automatically assigns a new healthy proxy and your session continues working, just with a different IP. For endpoints with cross-domain exit coherence enabled, the request may fail instead of silently switching IPs, because keeping the same browser identity can be more important than returning from a fresh exit. Support can confirm which behavior applies to your endpoint.
Q: Do sessions survive proxy server restarts?
A: Yes, in normal cases. Sessions are saved to disk during graceful restarts and zero-downtime version upgrades, then restored on startup - your IP assignment carries through. Sessions are only lost if the server crashes hard (power loss, kernel panic), if more than 24 hours have passed since your last request (TTL expiry), or if the upstream proxy you were assigned to has been removed from the pool. In all of those cases your next request automatically gets a fresh proxy assignment with no error.
Q: Can I choose which specific IP I get?
A: No. The proxy rotator assigns a proxy from the pool automatically. You control when to rotate, not which IP you get.
Q: I use IP-based authentication. Can I still use sticky sessions?
A: Yes. Use Hybrid Auth Mode - send a session ID in the username with an empty password: -session-YOURID:. Your IP is still used for authentication, but you get the session stickiness. See the "For IP-Based Authentication" section above.
Q: Will one session ID keep the same IP across every domain?
A: Not by default. Standard sticky sessions keep the same exit for the configured route handling the requested domain. Browser workflows often load several domains, such as the main site plus CDN, captcha, analytics, or font domains, and those domains may use different routes.
If cross-domain exit coherence is enabled for your proxy endpoint, the first pin-eligible request for that session establishes the exit, and later domains in the same session are forced through that same exit. This is useful for full browser workflows, but it also means you should not reuse one session ID across unrelated countries or target workflows.