A sticky residential proxy keeps the same home IP address for a whole session, so a login, a checkout or a multi-page flow comes from one visitor instead of a new address on every request. This guide explains what a sticky session is, how it works on a backconnect gateway, how it compares with rotating and static residential IPs, why IPs get blocked and where session consistency helps, what ends a session, and how to set one up in ProxyEmpire’s rotating residential proxies with a curl example.
The short version
A sticky session is a label on your proxy connection that tells the gateway to keep sending your traffic through the same residential device, so every request in that session leaves from the same IP. On ProxyEmpire the label is a session ID in the proxy username (for example -sid-123456), and a sticky session has no fixed time limit: the IP stays until you rotate it or the device behind it goes offline. Use it for anything with state: logins, carts, forms and multi-step flows.
What is a sticky residential proxy?
One home IP, held for a sessionA residential proxy sends your requests out through real home internet connections, so the website sees an IP address that belongs to an ordinary broadband customer rather than a data center. A rotating residential network has millions of these addresses, and by default it can hand you a different one for each new connection.
A sticky residential proxy is the same network used in a different mode. Instead of picking a new device for every connection, the gateway pins your traffic to one device and keeps it there. Every request you send in that session leaves from the same IP address, the same ISP and the same location, until the session ends.
“Sticky” is therefore a property of the session, not a separate kind of IP. The addresses come from the same residential pool as rotating traffic; what changes is how long you keep one of them. That is also what separates a sticky session from a static residential (ISP) proxy, where one fixed IP is assigned to you and stays yours: more on that in the comparison below.
Key takeaways
- A sticky session keeps one residential exit IP across many requests; rotation gives a new IP per connection.
- On a backconnect gateway the session is named in the proxy username, so the host and port never change.
- ProxyEmpire’s sticky sessions have no fixed time limit. The IP stays until you rotate it or the device goes offline.
- Use sticky for stateful work (logins, carts, forms, multi-page checks) and rotation for spreading large volumes of stateless requests.
- A sticky session is not a static IP: a residential device can go offline, so good code expects the IP to change and handles it.
What a sticky session keeps, and what it doesn’t
The IP is only half of a sessionHTTP on its own doesn’t remember anything between requests. Websites build sessions on top of it with cookies: RFC 6265 defines the Set-Cookie and Cookie header fields, which let a server store state in your browser or client and keep “a stateful session over the mostly stateless HTTP protocol”. When you log in, the site sets a session cookie, and every later request that carries it is treated as you.
A sticky proxy doesn’t create or store any of that. It only keeps the network address the same. The cookies, the login token, the cart and the browser fingerprint all live in your client, so a sticky session works best when the client keeps its own state too: a browser profile, a cookie jar in curl, or a Session object in Python.
Why does the IP matter if the cookie carries the session? Because many sites check that the two stay together. The OWASP Session Management Cheat Sheet recommends binding a session ID to client properties “such as the client IP address, User-Agent, or client-based digital certificate”, and says that a change in the middle of an established session is a strong sign of hijacking that can be used to alert or end the session. In practice that means an IP change halfway through a flow can log you out, trigger a verification step or empty a cart. A sticky session removes that source of friction for honest, multi-step work.
The cookie says who you are. The sticky IP makes sure the network doesn’t contradict it halfway through.
How sticky sessions work on a backconnect gateway
The session ID lives in the usernameProxyEmpire’s residential and mobile networks sit behind a backconnect gateway: you always connect to the same host and port, v2.proxyempire.io:5000, and the gateway picks the residential device your request leaves from. You never connect to the device directly. Your choices, such as country, city, ISP and session, travel in the proxy username, and the gateway reads them on every connection.
your client
username: YOUR_USERNAME-country-us-sid-123456
|
v
gateway v2.proxyempire.io:5000
reads country-us, looks up session 123456
|
+--> request 1 --> home device A --> exit IP 203.0.113.24
+--> request 2 --> home device A --> exit IP 203.0.113.24
+--> request 3 --> home device A --> exit IP 203.0.113.24
new session ID (sid-654321) --> home device B --> exit IP 198.51.100.77
device A goes offline --> session 123456 continues on a new IPThe session ID is the key. Requests that carry the same ID are routed to the same device for as long as it is available; a request with a different ID starts a different session, which normally gets a different IP. ProxyEmpire’s help centre describes it plainly: each sticky session has its own session ID (sid) in the proxy username, and to run many sticky sessions at once you generate a proxy list in which every line is a separate session.
The exact format is visible in the code samples on ProxyEmpire’s product pages, which connect to v2.proxyempire.io:5000 with the username r_username-country-us-sid-123456: country-us selects the United States and sid-123456 names the session. Your real username comes from the Proxy Manager in your dashboard, and the safest habit is to copy the full string from there rather than type it.
Because everything is in the username, switching from rotating to sticky, or from one city to another, never needs a new host, port or password. It also means any tool that accepts a username and password for a proxy can use sticky sessions, from curl and Python to browsers and anti-detect browser profiles. ProxyEmpire uses username and password authentication only; there is no IP allowlisting.
Sticky vs rotating vs static residential proxies
Three ways to use a residential IP| Rotating (new IP per request) | Sticky session | Static residential (ISP) | |
|---|---|---|---|
| Exit IP | A different residential IP for each new connection | One residential IP for the whole session | One fixed IP assigned to you |
| What changes the IP | Every new connection | You rotate it, or the device behind it goes offline | Nothing, while you keep the IP |
| Pool | 30M+ residential IPs in 179 countries and territories | The same pool | A fixed list of countries |
| Targeting | Country, region, city, ZIP, ISP, ASN, OS fingerprint | The same, at no extra charge | Country only |
| Billing | Per GB | Per GB | Per IP |
| Best for | Large volumes of stateless requests: price checks, SERP and catalogue data | Logins, carts, forms, multi-page flows, geo-testing | One identity for weeks, allowlisting, long-lived accounts you own |
| ProxyEmpire product | Rotating residential | Rotating residential (Same IP mode) | Static residential / ISP |
The choice comes down to how much state the job carries. Rotation spreads a large number of independent requests over many addresses, so no single IP carries a heavy load. A sticky residential proxy holds one address for as long as a task needs continuity. A static residential proxy goes further and gives you one address that stays assigned to you, which matters when a partner allowlists your IP or when you want the same identity on an account for weeks. Sticky and rotating sessions come with the same rotating residential plan and can run side by side from one account; our guide to sticky vs rotating proxies goes deeper into that choice, including timed rotation.
When to use a sticky session
Any flow where one visitor must stay one visitorLogins on accounts you own
Businesses manage their own accounts on marketplaces, ad platforms and social networks from many locations: a store operating in several countries, an agency working on client-owned profiles, a QA team logging in as test users. A sticky session gives each of those accounts one steady residential address for the length of the work, so the platform sees a normal session instead of a user who seems to jump between cities between clicks. Pair it with a separate browser profile per account so cookies never mix.
Checkouts and multi-step forms
A checkout is the textbook stateful flow. The cart, the shipping estimate, tax and payment steps are tied to one session, and a shop can check that session again at any step. With rotation, step three might arrive from a different country than step one. With a sticky session the whole flow comes from one address. This matters just as much for testing your own shop: a QA engineer checking the checkout from the United States, Germany and Japan needs each run to stay in one place.
Geo-testing and localisation checks
Marketing and product teams use residential IPs to see what customers in a given city see: localised pricing, ad placements, cookie banners, currency, redirects and search results. A single page check can rotate freely, but a journey from a landing page to a product page to checkout needs the same location throughout, or the site may change language or currency halfway. Target the city or ZIP code you need, hold it with a sticky session, and every page in the journey reflects the same place.
When rotation is the better choice
If each request stands alone, such as collecting prices from thousands of product pages, monitoring rankings or gathering public catalogue data, rotation is usually better: the load is spread over many addresses and one slow device doesn’t hold up the job. Many projects use both: a sticky session for the part of the flow that needs continuity, such as a login or a search with filters, and rotation for the bulk collection that follows.
What a sticky session is not for: getting around a ban. If a website has blocked your account or your traffic for breaking its rules, a new IP doesn’t change that decision, and ProxyEmpire isn’t the tool for it. The same goes for creating accounts in bulk. Sticky sessions exist to keep honest, multi-step work stable.
Why IPs get blocked, and where session consistency helps
Rate limits, reputation and mid-session changesMost blocks that ordinary users and businesses run into are not personal. They are automatic responses to patterns that a site’s defences associate with abuse. Knowing the common ones makes it easier to design traffic that stays well within what a site expects.
| Cause | What the site sees | What helps |
|---|---|---|
| Rate limits | Too many requests from one address in a short time. The standard reply is HTTP 429 Too Many Requests, often with a Retry-After header. | Slow down, respect Retry-After, and spread independent requests over rotating IPs. |
| Address reputation | An address that others have abused. Sites may put such addresses in a “penalty box” or ask for a CAPTCHA. | Residential IPs from a large pool, and a fresh session if the address you were given is being challenged because of someone else’s traffic. |
| Network type | Traffic from a hosting provider on a site built for consumers. | Residential or mobile IPs for consumer-facing sites. |
| Mid-session changes | A logged-in session that suddenly arrives from a new IP, ISP or country. | A sticky session for the whole flow, with cookies kept in the same client. |
| Location mismatch | An account or cart set up in one country and used from another. | Targeting the right country or city, held by a sticky session. |
The first two causes are described in the standards. RFC 6585 defines 429 Too Many Requests as the response when “the user has sent too many requests in a given amount of time”, and its example is a site allowing 50 requests an hour per logged-in user. RFC 6269, which catalogues the problems of shared IPv4 addresses, describes the penalty box: a server that sees too many requests from one address in a short time may deny requests from it for a while, or require a CAPTCHA. A 403 Forbidden, which RFC 9110 defines as the server refusing a request it understood, is the bluntest version.
The fourth cause is where sticky sessions earn their keep. As the OWASP guidance above shows, sites are encouraged to treat an IP change in the middle of an established session as suspicious. A rotating proxy used for a login flow creates exactly that signal on every click. A sticky session doesn’t: from the site’s point of view, one person on one home connection logged in, browsed and checked out.
Consistency cuts both ways, though. A sticky IP that sends hundreds of requests a minute will still hit rate limits, because it is still one address. Keep the pace of a sticky session close to what a person would do in that flow, and send high-volume, stateless work through rotation instead.
What ends a sticky session
There is no timer, but there is a real deviceProxyEmpire doesn’t put a fixed time limit on sticky sessions. In the Proxy Manager’s Same IP mode, the help centre says the session keeps the same IP for as long as possible, until you rotate it or the device behind it goes offline. That is the honest way to think about it: the address belongs to a real home connection, and a sticky session lasts as long as that connection is available to the network. A session ends, or moves to a new IP, when:
- The peer device goes offline or changes its IP. The router restarts, the broadband provider hands the home a new address, or the device leaves the network. The next request in your session then leaves from a different IP. This is the one cause you can’t control, and it is why code should always expect it.
- You rotate the session. Click Rotate session in the Proxy Manager, rotate it through the API, or simply send a different session ID in the username.
- You change the targeting. Country, city and other targeting are part of the username, so a new location means a new username, and you should treat it as a new session.
- You chose a timer. If you picked Custom TTL instead of Same IP, the IP changes on the timer you set. The help centre notes that the timer is the longest an IP is kept, not the shortest: if the device goes offline earlier, the IP changes sooner.
Some providers publish fixed session lengths. ProxyEmpire’s Same IP mode has none, which is useful for long flows, but it doesn’t turn a residential device into a server. When you need an address that is guaranteed to stay the same for days or weeks, use a static residential proxy instead.
How to set up a sticky session in ProxyEmpire
Proxy Manager, then one username- Open Proxy Manager. Log in to the dashboard and open Proxy Manager (the Connection Builder), then pick the Residential or Mobile tab.
- Set the targeting. Choose the country, then any narrower targeting the task needs: region, city, ZIP, ISP, ASN or OS fingerprint. Targeting is included at no extra charge.
- Choose the rotation mode. Pick Same IP for a sticky session. Every request gives a new IP per connection; Custom TTL rotates on a timer you set.
- Copy the proxy string. Copy the host, port, username and password, or the full proxy string. The username now contains your session ID. Use Test proxy settings to check the connection.
- Need many sessions? Use the Proxy list panel to generate as many endpoints as you need; every line is a separate sticky session. There is no limit on concurrent sessions.
# 1. Same session ID = same exit IP. Run it twice: both lines print the same address.
curl -x "http://YOUR_USERNAME-country-us-sid-123456:YOUR_PASSWORD@v2.proxyempire.io:5000" https://ifconfig.me
curl -x "http://YOUR_USERNAME-country-us-sid-123456:YOUR_PASSWORD@v2.proxyempire.io:5000" https://ifconfig.me
# 2. A different session ID starts a new session, usually on a different IP.
curl -x "http://YOUR_USERNAME-country-us-sid-654321:YOUR_PASSWORD@v2.proxyempire.io:5000" https://ifconfig.me
# 3. The same, with the credentials in -U instead of the proxy URL.
curl -x http://v2.proxyempire.io:5000 -U "YOUR_USERNAME-country-us-sid-123456:YOUR_PASSWORD" https://ifconfig.me
# 4. A multi-step flow: one session ID plus one cookie jar for every step.
P="http://YOUR_USERNAME-country-us-sid-123456:YOUR_PASSWORD@v2.proxyempire.io:5000"
curl -x "$P" -c jar.txt -b jar.txt https://example.com/login
curl -x "$P" -c jar.txt -b jar.txt https://example.com/account
# 5. SOCKS5 works on the same host, port and credentials.
curl -x "socks5h://YOUR_USERNAME-country-us-sid-123456:YOUR_PASSWORD@v2.proxyempire.io:5000" https://ifconfig.meA few details from the curl documentation are worth knowing. -x (--proxy) treats a proxy with no scheme or with http:// as an HTTP proxy, and socks5h:// asks for SOCKS5 with the hostname resolved by the proxy. -U (--proxy-user) passes the username and password separately. Credentials inside the proxy URL are URL-decoded, so a password containing @ or : must be written as %40 or %3a. -c writes cookies to a file after each request and -b sends them back, which is what keeps a login alive across steps. For more options, see our curl proxy guide.
import requests
# one sticky session: same session ID for every request in this flow
proxy = "http://YOUR_USERNAME-country-us-sid-123456:YOUR_PASSWORD@v2.proxyempire.io:5000"
proxies = {"http": proxy, "https": proxy}
s = requests.Session() # keeps cookies between requests
print(s.get("https://ifconfig.me", proxies=proxies, timeout=30).text)
s.get("https://example.com/login", proxies=proxies, timeout=30)
s.get("https://example.com/account", proxies=proxies, timeout=30)The Requests documentation shows the http://user:password@host proxy syntax and notes that a Session object persists cookies across all requests made from it: the Python equivalent of the cookie jar above. If you prefer a browser, ProxyEmpire’s own ProxyEmpire Proxy Manager extension for Chrome takes the same host, port, username and password and switches between proxy profiles in one click, and on Android, ProxyEmpire’s free ProxyEmpire Proxy Manager app from Google Play takes the same connection details. The help centre’s page on how to use sticky sessions covers the dashboard steps.
Keeping sticky sessions stable
Good habits for long flows- One session per task or account. Give each account, test user or flow its own session ID and its own cookie store. Never share one session between two identities.
- Check the exit IP at the start. A request to an IP echo service such as ifconfig.me tells you which address the session got, so you can log it and notice when it changes.
- Handle a change gracefully. If the device goes offline, the next request arrives from a new IP. Detect it, then either finish the step and continue, or start a fresh session and sign in again. Don’t loop on retries.
- Keep the pace human. A sticky session is one visitor. Send requests at the rate a person moving through that flow would, and move bulk work to rotation.
- Target only as narrowly as you need. One ISP in a small city has far fewer devices than a whole country, so there are fewer addresses to hold your session. Target the country, add the city if the task needs it, and stop there.
- Remember what’s blocked. Only ports 80 and 443 are open by default, UDP isn’t supported, and financial, government, banking, payment and crypto exchange sites are blocked on every proxy type unless they are unlocked after KYC and a use-case review.
Sticky sessions on mobile and datacenter proxies
The same idea on other networksSticky sessions aren’t limited to home connections. ProxyEmpire’s rotating mobile proxies, with 4M+ mobile IPs in 174 countries, use the same Proxy Manager modes and the same session ID in the username, with carrier targeting included. A sticky mobile session keeps one carrier IP for the flow, which suits apps and mobile sites that expect a phone on a mobile network. Mobile carriers can reassign addresses when a device reconnects, so the same advice applies: expect a change and handle it.
Rotating datacenter proxies give a new IP on every request by default. For a sticky session there, the help centre says to click “Sticky Sessions” to add a session ID to the username, and that you can also create your own 8-digit session IDs. Datacenter IPs suit fast, low-cost jobs on sites that accept hosting traffic; for consumer sites, residential or mobile sessions are the better match.
If you are choosing a provider rather than a session type, our comparison of the best sticky residential proxies lines up session controls, pools and prices across providers.
Sticky residential proxy FAQ
Short answersWhat is a sticky IP?
An exit IP that stays the same for a whole proxy session instead of changing with every request. On a residential network it is a real home IP held for you by the gateway.
How long does a sticky session last on ProxyEmpire?
There is no fixed time limit. In Same IP mode the IP stays until you rotate it or the device behind it goes offline, so the length depends on that device, not on a timer.
Is a sticky residential proxy the same as a static residential proxy?
No. A sticky session holds an IP from the rotating residential pool for as long as the device is available. A static residential (ISP) proxy is one fixed IP assigned to you, billed per IP.
How do I get a new IP in a sticky session?
Change the session ID in the username, click Rotate session in the Proxy Manager, or rotate the session through the API.
Can I run many sticky sessions at once?
Yes. Generate a proxy list in the Proxy Manager: every line is a separate session with its own IP, and there is no limit on concurrent sessions.
Do sticky sessions cost more than rotating ones?
No. Sticky and rotating sessions come with the same residential plan, billed per GB, and all targeting is included at no extra charge.
Why did my sticky IP change?
Most often the residential device behind it went offline or received a new IP from its provider. Start a new session, or continue on the new IP if your flow allows it.
Can a sticky proxy get around an IP ban?
That isn’t what it is for. A sticky session keeps legitimate multi-step work stable; it doesn’t change a site’s decision to block an account or its traffic, and ban evasion isn’t a supported use.
Do sticky sessions work with SOCKS5?
Yes. HTTP and SOCKS5 use the same host, port, username and password, so the session ID works the same way in both.
References
Primary documentation- IETF — RFC 6265, “HTTP State Management Mechanism” (cookies). rfc-editor.org/rfc/rfc6265
- OWASP — Session Management Cheat Sheet, “Binding the Session ID to Other User Properties”. cheatsheetseries.owasp.org
- IETF — RFC 6585, “Additional HTTP Status Codes” (429 Too Many Requests). rfc-editor.org/rfc/rfc6585
- IETF — RFC 6269, “Issues with IP Address Sharing” (abuse logging and penalty boxes). rfc-editor.org/rfc/rfc6269
- IETF — RFC 9110, “HTTP Semantics” (403 Forbidden, 407 Proxy Authentication Required). rfc-editor.org/rfc/rfc9110
- curl — man page:
-x/--proxy,-U/--proxy-user,-b,-c. curl.se/docs/manpage - Requests — Advanced usage: Session objects and proxies. requests.readthedocs.io
- IETF — RFC 5737, “IPv4 Address Blocks Reserved for Documentation” (example IPs in Figure 1). rfc-editor.org/rfc/rfc5737
Sticky sessions with no fixed time limit
30M+ residential IPs in 179 countries and territories, sticky or rotating sessions from the same plan, targeting down to city, ZIP, ISP and ASN at no extra charge, no limit on concurrent sessions, and 24/7 support from real people. The $1.97 trial includes 100 MB of residential and 50 MB of mobile traffic.
