Sticky vs rotating proxy: how to choose an IP model for your sessions?

This guide defines the three session models (per-request rotation, timed sticky session, static IP), explains what breaks when the IP changes mid-session and how per-IP rate limits affect the choice. It ends with a scenario table, hybrid patterns and a Python example that separates sticky identities from a rotating pool. The examples use the gateway gw.weproxy.com.tr:8989 and the placeholders USER and PASSWORD for credentials.

What is the difference between sticky, rotating and static IPs?

All three models answer the same question differently: will the target site see two consecutive requests from the same IP? The proxy type (residential, mobile, datacenter, ISP) decides where the IP comes from. The session model decides how long that IP stays with you. For choosing a type, see the residential, mobile, datacenter and ISP comparison; this article covers only the session model.

Per-request rotation

In rotating mode the gateway picks a different exit IP from the pool for each new request or each new connection. The target site may see 1,000 requests from 1,000 different addresses. This spreads per-IP counters, but no "same user" impression forms between requests.

In practice most gateways rotate at the connection level. For an HTTPS request the client opens a tunnel to the proxy with CONNECT; if the same keep-alive tunnel is reused, later requests may leave through the same exit. If you expect a different IP per request, send each request on a new connection.

Timed sticky session

In a sticky session a session ID is bound to a specific exit IP. All requests carrying that ID leave from the same IP until the time runs out or the exit device goes offline. When the time is up, the same ID gets a new IP from the pool.

In residential and mobile pools the IPs come from real devices, so the sticky duration is an upper limit, not a guarantee. If the device drops off the network, the IP can change before the session expires. Plan critical steps so they fit comfortably inside the time limit.

Static IP

With a static proxy the IP is assigned to you for the package period and is not shared with a pool. There is no session duration; the IP stays the same until you change it or the package ends. This model is used for accounts that must keep the same identity for weeks, panels that require an IP whitelist and long-running automation.

How is a sticky session configured?

Most providers enable sticky behavior in one of two ways. The first is adding a session ID to the username: the username carries a session ID you choose, and sometimes a duration or country parameter. As long as the gateway sees the same ID, it uses the same exit. The second is port-based separation: some providers reserve certain port ranges for sticky and others for rotating.

In WeProxy residential and mobile pools, sticky behavior is enabled by adding a session ID to the username. With this method the same exit IP can be held for up to 24 hours in the residential pool and up to 60 minutes in the mobile pool. The exact username format varies by product; copy the correct format from the connection details in the customer panel instead of guessing it.

Three rules help when choosing session IDs:

1. One identity, one ID. Each account or browser profile should use its own session ID. If two profiles share an ID, the target site sees two different users from the same IP.
2. Store the ID persistently. If the process generates a new random ID on restart, the same account comes back on a new IP. Keep the ID in a file or database together with the profile record.
3. Change the ID when you need a new IP. If the IP is blocked, retrying with the same ID returns to the same exit. A new ID means a new exit.

The quickest way to confirm the setup works is to query your exit IP twice in a row with the same session ID. In a browser, the My IP tool does this check; on the command line, api.ipify.org is enough. If both values match, the session is sticky.

What breaks when the IP changes mid-session?

Web applications recognize users by cookies, but many also record which IP the cookie arrived from. RFC 6265 does not bind cookies to IPs; the IP check is added by the application and its security layer. That is why the same request passes on one site after an IP change and drops the session on another.

Typical breakages:

• The login session drops. If the session cookie is matched to an IP or ASN, a request from a new IP counts as outside the session. The user is sent back to the login page or asked for extra verification.
• The cart and checkout break. The cart is tied to the session on the server side. If the IP and country change during payment, fraud checks can stop the transaction or reset the cart.
• The CSRF token is rejected. A form carries a token generated with the page, and that token is tied to the session cookie. If the session is renewed because of the IP change, the old token becomes invalid and the form returns 403. See the MDN explanation of CSRF for the mechanism.
• Bot-protection cookies are wasted. Some protections issue a verification cookie on the first visit and evaluate it together with the IP. In rotating mode every request comes from a new IP, so verification starts over each time.
• Risk signals accumulate. The same account appearing from different cities or countries within a few minutes can be flagged as an "unusual sign-in" by account security systems.

What these problems share is state. For stateless requests such as product lists, search results or public price pages, an IP change breaks nothing. A stateful flow must be completed from the same IP from start to finish.

How do per-IP rate limits affect the rotation decision?

Rate limits are usually kept per IP. The server counts requests from the same address over a period and returns 429 Too Many Requests once the threshold is exceeded. RFC 6585 defines this code; the server usually states the wait time in a Retry-After header.

In sticky and static models all requests go to one IP’s counter. So in a sticky session the request rate must stay below the limit the target accepts for that IP. In rotating mode the counter is spread across the pool; the number of requests per IP stays small.

Rate limits are not tied only to IPs. Some sites set limits per account, session cookie, API key or device fingerprint. In that case rotating the IP does not reset the counter; requests from a logged-in account are written to the same account counter whatever IP they come from.

WeProxy packages have no thread or concurrent session limit. So when you get 429, the limit comes from the target site. For diagnosis and backoff strategy, see the proxy error codes guide. Trying to get around a rate limit by growing the pool is not a solution if it violates the target’s terms of use.

When should you use sticky and when rotating?

Ask two questions: does the flow carry state, and how long must the same identity live? The table below maps common scenarios to these two questions.

Ad verification has two different needs. To see how an ad is shown in different regions, rotating fits. To follow a click’s redirect chain from start to end, the same IP is needed along the chain; a short sticky session is used here. Details on SEO, scraping and ad work are in the use cases article and on the web scraping page.

In SERP checks, rotation should change the IP, not the country. Keep country targeting fixed and rotate the IP; a random country corrupts ranking data. For targeting options, see the country, city and ASN targeting guide.

How do you combine sticky and rotating?

Most real workflows use both models. The stateless part leaves from the rotating pool, the stateful part from a sticky session or a static IP. This split both spreads the counter and protects the session.

Common hybrid patterns:

• Discovery rotating, detail sticky. Category and list pages are crawled with rotating IPs. Detail pages that require login or a multi-step form are opened with a sticky session.
• Sticky per account, different IPs across accounts. Each account stays on one IP with its own session ID. Accounts leave from different IPs, so no IP shows more than one account.
• Static main identity, rotating helper requests. The account panel is managed from a static IP. Public data needed for the same job (for example a competitor price list) is collected by a separate rotating flow.
• Short sticky blocks. On sites that do not need a session but where several consecutive requests look more natural from one IP, sticky blocks of a few minutes are used; when a block ends, work continues with a new ID.

The most common mistake in a hybrid setup is letting both flows share one cookie jar. If cookies from the rotating flow mix with the sticky session’s cookies, the site sees the same session from different IPs. Each flow should use its own HTTP session and cookie store.

How do you build sticky identities and a rotating pool in Python?

The example below keeps the two models apart. Each sticky identity has its own session ID and its own requests.Session object; cookies and connections stay with that identity. Rotating requests are sent without a session object, on a new connection each time.

import uuid
import requests

GATEWAY = "gw.weproxy.com.tr:8989"
PASSWORD = "PASSWORD"
ROTATING_USER = "USER"
# Put the sticky username format from your panel here; {sid} marks the session ID
STICKY_USER_TEMPLATE = "USER_STICKY_FORMAT_{sid}"


def proxy_url(user):
    return f"http://{user}:{PASSWORD}@{GATEWAY}"


class StickyIdentity:
    def __init__(self, name, sid=None):
        self.name = name
        self.sid = sid or uuid.uuid4().hex[:12]  # store it persistently
        url = proxy_url(STICKY_USER_TEMPLATE.format(sid=self.sid))
        self.session = requests.Session()
        self.session.trust_env = False
        self.session.proxies = {"http": url, "https": url}

    def get(self, url, **kwargs):
        return self.session.get(url, timeout=(10, 30), **kwargs)

    def post(self, url, **kwargs):
        return self.session.post(url, timeout=(10, 30), **kwargs)


def rotating_get(url):
    # No session object, no keep-alive: every call is a new connection
    proxy = proxy_url(ROTATING_USER)
    return requests.get(
        url,
        proxies={"http": proxy, "https": proxy},
        headers={"Connection": "close"},
        timeout=(10, 30),
    )


identities = {name: StickyIdentity(name) for name in ("profile-a", "profile-b")}

for name, identity in identities.items():
    first = identity.get("https://api.ipify.org").text
    second = identity.get("https://api.ipify.org").text
    print(name, first, second, "same IP" if first == second else "IP changed")

for _ in range(3):
    print("rotating:", rotating_get("https://api.ipify.org").text)

Replace the STICKY_USER_TEMPLATE line with the format shown in your panel. On a rotating product, requests sent without a session parameter get an exit from the pool; confirm your package’s default behavior in the panel. trust_env = False prevents an HTTP_PROXY environment variable from overriding the proxy in your code.

In this structure one account is one StickyIdentity object. Login, cart and form requests always go through that object’s get and post methods; the CSRF token and session cookie stay in the same cookie store. If the IP is blocked, create a new object with a new sid and log in again. For more connection examples, see the Python integration page. How connection reuse affects rotation, and the httpx and aiohttp equivalents, are covered in the guide to using a proxy in Python.

Which WeProxy product fits which session model?

Once the session model is chosen, the product choice narrows. The mapping below relies only on features published on the product pages; starting packages and current terms are on each product page.

Rotating Residential IPv4 offers both models in one package: rotating without a session ID, sticky with one. It suits teams that want to separate bulk scraping from login steps within the same package. Static Residential IPv4 is for accounts whose identity must live for days and for panels that require a whitelist. Sticky IPv6 provides sessions with a selectable duration on IPv6-capable targets, with exits in the Netherlands, the United States, the United Kingdom, Germany and Canada. Before buying, confirm that the target accepts IPv6 with the test in the IPv4 vs IPv6 proxy guide.

Username/password and IP whitelist authentication work over HTTP and SOCKS5 on all packages. There is no thread or concurrent session limit; the limit is set by the target site’s own rules.

Common mistakes and a checklist

Most session model mistakes fit a few recurring patterns:

• Putting a login flow on rotating. List crawling can stay rotating, but every step after login should be sticky.
• Treating sticky as permanent. The sticky duration is an upper limit. For an identity that lasts days, choose a static IP.
• Loading high concurrency onto one sticky IP. All requests go to the same counter. Split the work across several session IDs or lower the rate.
• Expecting rotation with keep-alive. If the same tunnel is reused, the IP may not change. Open a new connection for rotating requests.
• Leaving the country random. In SERP and pricing work the country should stay fixed and only the IP should rotate.

A short checklist before you start:

1. Does the flow carry state? If yes, sticky or static; if no, rotating.
2. How long must the identity live? Minutes to hours means sticky, days means a static IP.
3. Does each account or profile use a separate session ID and a separate cookie store?
4. Do two consecutive queries with the same ID return the same IP? Check with the My IP tool.
5. Is the request rate below the target’s per-IP and per-account limits? Is Retry-After respected?
6. Does the automation comply with the target site’s terms and the WeProxy acceptable use rules?

Sticky gives continuity, rotating gives distribution. First check whether the flow carries state, then how long the identity must live. Those two answers choose the model; proxy type and country come after.