Sticky Sessions

Sticky sessions let you keep the same egress IP for a defined time window so cookies and logged-in state persist across steps. If you are choosing between long-lived and fast-rotating behavior, start with the static vs rotating proxies guide.

What is a sticky session?

A sticky session is a connection mode where the proxy keeps assigning you the same exit IP for a fixed duration called TTL. This preserves cookies, tokens, and in-progress forms across requests that happen within that window.

In practice, the provider “pins” your client to one IP based on a session identifier. You can open, reuse, and close TCP connections during the TTL and still keep the same public IP. Once TTL expires, the next request gets a new IP.

Default rotation time (TTL)

Default rotation time is the provider’s built-in TTL for stickiness, commonly 1–30 minutes. Shorter TTLs reduce risk of rate limits but can break long flows; longer TTLs improve continuity but decrease IP churn.

Most networks set a sane default and allow you to override it per session. Aim to pick the smallest TTL that still completes your workflow, then increase only if you see broken checkouts, OTP loops, or frequent re-auth.

How sticky sessions are implemented

Providers usually implement stickiness via either a dedicated endpoint that maps 1:1 to a session, or a session key you send with each request. Both approaches attach a TTL so the mapping auto-expires.

• Dedicated port or endpoint: gw.example.com:9001 stays bound to an IP for N minutes. New connections to the same port reuse that IP until TTL ends.
  
• Session parameter: gw.example.com:9000 with ?session=abc123 or username=customer-session-abc123. Each unique session value pins you to a specific IP for the TTL.
  

Quick examples

cURL (HTTP proxy with session key):

cURL (SOCKS5 with dedicated port):

curl -x socks5h://user:[email protected]:9101 https://example.com/

Python requests with HTTP proxy:

proxies = {
  "http":  "http://user-session-abc123:[email protected]:9000",
  "https": "http://user-session-abc123:[email protected]:9000",
}
r = requests.get("https://example.com/cart", proxies=proxies, timeout=30)

Tip: keep the session token stable while you need continuity. Change it to force a new IP before TTL ends.

Cookie and session pinning

Sticky sessions complement browser cookies and app tokens by ensuring that your network identity (IP) does not unexpectedly change mid-flow. This lowers false positives in device fingerprint and risk scoring.

Watch for “leaks”: if some calls bypass the proxy, targets will see mixed IPs and may reset sessions. Ensure all HTTP(S) and WebSocket calls go through the same sticky session while the flow runs.

Where sticky sessions fit vs fully static IPs

Sticky sessions simulate a “temporary static IP” for minutes, not days. They are ideal when you need continuity across a checkout, onboarding wizard, or light account work, but do not require a permanently assigned IP.

Choose full static when targets firmly bind accounts to a long-term IP, when you need reverse DNS control, or when you must keep the very same IP across days. Choose sticky when you only need continuity for the workflow duration and can accept an IP change after completion.

Tuning TTL safely

A good default is 5–15 minutes. If you see mid-flow challenges or logout prompts, raise TTL in small steps. If you hit rate limits, blocks, or low throughput, lower TTL or rotate the session more often.

Use separate session IDs per concurrent user, tab group, or task. Reusing one session across unrelated jobs increases correlation and lowers the value of rotation.

Common TTL reference points

• Forms, carts, or OTP steps: 5–10 minutes
  
• Long onboarding wizards: 10–20 minutes
  
• Background polling or low-rate API reads: 15–30 minutes
  

Network type differences

DC and ISP networks usually allow longer and more stable sticky windows because IPs are served from data centers and remain available for extended periods. Residential and mobile networks often have shorter practical windows due to peer availability, CGNAT, or carrier policies; a longer TTL may end early if the peer disappears.
For a refresher on how each network allocates and rotates IPs, see the proxy network type overview.

Concurrency and session hygiene

One session should map to one logical user or task. If you open dozens of parallel connections on the same session, targets may upgrade the risk score even though the IP is stable.

Use a session pool to separate tasks:

• Assign session=a1..aN for checkout team
  
• Assign session=b1..bN for support tasks
  
• Periodically recycle old sessions to refresh IPs and reduce correlation
  

Troubleshooting checklist

The two most common issues are “IP changed mid-flow” and “session never rotates.” Use this checklist to isolate them.

• Confirm you are passing the same session value on every request during the flow.
  
• Verify the provider’s TTL and whether it can be overridden.
  
• Check that all sub-requests, XHRs, and WebSockets use the same proxy settings.
  
• Ensure your app is not opening a second proxy profile with a different session.
  
• If the IP never rotates, you might be on a dedicated or static plan; change the session key or endpoint to force a swap.
  
• If the IP rotates too early, the upstream pool may have reclaimed the peer; shorten flows or lower concurrency per session.
  

Pros and cons

Pros

• Keeps cookies, tokens, and device posture aligned with one IP during workflows.
  
• Fewer login challenges and fewer broken multi-step actions.
  
• Simple client control via session parameter or port.
  

Cons

• Longer TTL reduces churn and may raise correlation or rate-limit risk.
  
• Premature peer loss on residential or mobile networks can still break continuity.
  
• Forgetting to rotate session IDs leads to overused IPs and faster bans.
  

Typical use cases

• Completing carts, top-ups, and payment confirmation steps.
  
• Multi-step forms, onboarding, and KYC wizards where one IP per run is expected.
  
• Light account work where a truly static IP is unnecessary.
  
• API polling where IP stability for a few minutes improves cache hits or lowers friction.
  

Configuration patterns

Username/Password session pattern

username: customer-session-<unique>
password: <secret>
proxy:    gw.example.com:9000

Query parameter session pattern

http://gw.example.com:9000?session=<unique>
socks5://gw.example.com:9100?session=<unique>

Dedicated sticky ports

gw.example.com:9201  -> TTL 10m
gw.example.com:9202  -> TTL 20m
gw.example.com:9203  -> TTL 30m

Operational tip: prefix sessions by task and timestamp, for example cart-20251022-uuid. Rotate the session string between jobs to guarantee a new IP.

FAQs

How do I force a new IP before TTL ends?
Change the session value or switch to a different sticky port. That breaks the pin and assigns a new IP immediately.

Why did my sticky session change IP early?
The upstream peer dropped or the provider reclaimed it. This is more common on residential or mobile networks. Shorten the flow, lower concurrency, or retry with a fresh session.

Is a longer TTL always better?
No. Longer TTL improves continuity but increases correlation and the chance of rate limits. Use the smallest TTL that still completes your flow.

Can I run multiple tabs on one session?
You can, but keep total concurrency modest. If tabs are unrelated, use separate session IDs to avoid linking activities.

Does sticky work over both HTTP and SOCKS5?
Yes. Stickiness is handled at the gateway, not by the HTTP vs SOCKS protocol, as long as you pass the same session identity.

Related in this topic

• Rotation Types
  
• IP Pools & Gateway Endpoints