Most proxy providers list "sticky proxies" and "rotating proxies" as separate products. Some charge differently for each. The framing implies a meaningful architectural distinction, like you need to choose one and stick with it.

That's not how it works. Sticky and rotating aren't two types of proxies. They're two session modes on the same residential IP pool, controlled by a single parameter in the username string. With sessid in the username, requests stay on the same IP. Without it, each request gets a fresh one. Same endpoint, same plan, same bandwidth budget, completely different behavior.

Understanding the sticky vs rotating proxies distinction at this level changes how you architect pipelines. Most teams use one mode for everything. Production pipelines that handle multiple workflow types need both.

What Is Rotating Mode? (The Default)

Rotating is what happens when you make a request without a sessid parameter. The gateway picks an available residential IP from the pool, routes your request through it, and that's the end of that IP's involvement. The next request gets a different one. No memory, no persistence, no continuity between requests.

This is the correct mode for the majority of proxy use cases:

• Scraping product catalogs - each page is an independent request. There's no reason for consecutive pages to share an IP.
• Rank tracking - each keyword query is stateless. IP diversity maximizes the authenticity of each result.
• Price monitoring - pulling prices from 500 URLs benefits from 500 different residential IPs, not one IP making 500 requests.
• Ad verification - each impression check is independent. Rotating ensures each check comes from a fresh perspective.

The benefit of IP rotation is straightforward: no single IP accumulates enough requests to build a behavioral profile that anti-bot detection systems can flag. Each request looks like a different person browsing once. That's exactly what it is, a different real device on a different real ISP network.

The limitation is equally straightforward: if your workflow depends on the target site recognizing the same user across multiple requests, rotating breaks it. Login state, shopping carts, multi-step forms — all of these require the same IP across a sequence of requests.

What Is a Sticky Session? (And How It Works Technically)

What is a sticky session in proxies? A sticky session is a configuration mode where all requests sharing the same sessid value route through the same residential IP for the duration defined by sesstime. It is not a separate proxy type, it draws from the same residential proxy pool as rotating mode. The only difference is that the gateway holds an IP assignment for a defined period rather than releasing it after each request.

The mechanism: when a request arrives with a sessid, the gateway checks whether that session ID has an active IP assignment. If yes, the request routes through that same IP. If the session has expired or the device has gone offline, the gateway assigns a new residential IP from the same country and holds it for the new session window.

In production testing on Magnetic Proxy's residential network, sticky sessions maintain IP consistency for the full sesstime window in the vast majority of cases. When a residential device goes offline mid-session, the system assigns a replacement IP from the same country pool, which means the session continues but the IP changes. Workflows that are sensitive to this should validate the IP at the start of each multi-step sequence.

QC-1: "Sticky and rotating are not two different types of proxies, they are two session modes available on the same residential proxy pool. The difference is a single parameter in the proxy username string: include a sessid value and every request in that session routes through the same residential IP. Omit it and each request gets a fresh IP from the pool."

QC-2: "The sesstime parameter controls how long a sticky session holds its assigned IP, expressed in seconds, with a default of 1,800 seconds (30 minutes) if not specified. Choosing the right session duration is an architectural decision: too short and multi-step workflows break; too long and the IP accumulates enough requests to trigger behavioral pattern detection."

QC-3: "A production pipeline can use both modes simultaneously on the same proxy plan. Route high-volume scraping requests through rotating mode for IP diversity. Route login sequences, checkout flows, and account operations through sticky sessions for state continuity. The switch is a change in the username string — no plan upgrade, no separate endpoint."

Can I use sticky and rotating on the same proxy plan? Yes, the mode is set per-request in the username string. The same plan, credentials, and endpoint support both modes simultaneously. A pipeline that runs rotating requests for catalog scraping and sticky sessions for login flows is using one plan and one endpoint with two username string configurations.

The sesstime Parameter: Session Duration as a Pipeline Design Decision

sesstime defaults to 1,800 seconds — 30 minutes — when not specified. Most guides treat this as a fixed property. It's a variable you should tune for each workflow.

The sessid parameter and sesstime parameter together define session duration behavior. A sesstime that's too short breaks multi-step flows mid-sequence. A sesstime that's too long creates a different problem: an IP that stays assigned for an extended period accumulates a request history. Anti-bot systems that analyze behavioral patterns across time will eventually see an IP making hundreds of requests — even spread over 30 minutes, that pattern is detectable.

Pro Tip: Default sesstime is 1,800 seconds — 30 minutes. For login-to-checkout flows that complete in under 5 minutes, set sesstime=300 to minimize the window during which the IP can accumulate suspicious request patterns. Reserve longer sessions only for workflows that genuinely require them.

Practical sesstime guidelines by workflow type:

• Login + single action: 300 seconds (5 min)
• Checkout flow (login → cart → payment): 300–600 seconds
• Account creation (multi-step signup): 600–900 seconds
• Extended account management session: 900–1,800 seconds

What happens when the residential device disconnects: the gateway assigns a new IP from the same country. The session ID remains valid and the new IP takes over for the remaining sesstime window. For most workflows this is acceptable — the session continues without error. For workflows where IP consistency is critical (some account platforms flag mid-session IP changes), build a validation step that checks the IP at the start of the sequence and aborts if it changes unexpectedly.

When to Use Each Mode: The Decision Framework

When should you use sticky sessions instead of rotating proxies?

Use sticky sessions when:

1. Your workflow requires login state persistence - the session cookie issued at login must be recognized by subsequent requests from the same IP.
2. You're completing a checkout or payment flow - most e-commerce platforms bind the cart and payment token to the originating IP. An IP change mid-checkout triggers a fraud check or invalidates the session.
3. You're creating or managing accounts - signup flows with email verification, CAPTCHA, and profile setup require IP consistency across 5–15 steps.
4. You need consistent geo-location across dependent requests - if step 1 of a workflow needs to appear as New York and step 2 must appear as the same location, sticky sessions with geo-targeting parameters lock both the IP and the location.
5. The target site performs mid-session IP validation - some platforms explicitly check that the IP hasn't changed between the authentication request and subsequent API calls.

Use rotating mode when:

• Scraping product catalogs, SERPs, or price pages at scale
• Running rank tracking across multiple keywords — each query is stateless
• Verifying ad placements across locations — each verification is independent
• Collecting data from multiple URLs where no session state is required
• Any workflow where each request can succeed or fail independently without affecting others

In production pipelines using Magnetic Proxy's residential network, here's how use cases map to session modes:

Full Working Code - Switching Between Modes in the Same Pipeline

Python implementation that uses rotating mode for catalog scraping and sticky sessions for stateful workflows on the same endpoint and credentials.

Here's what session continuity failure looks like in practice. A pipeline scraping an e-commerce platform first collects 10,000 product pages using rotating proxies — clean, fast, no blocks. The same pipeline then attempts to simulate checkout flows using the same rotating configuration. The first request (product page) uses IP A. The second request (add to cart) uses IP B. The site's fraud detection sees a cart addition from an IP that never viewed the product — flags it immediately. Using sticky sessions with a 300-second window on the checkout sequence, both requests route through the same residential IP and the flow completes cleanly.

# Sticky vs. rotating proxy modes on the same Magnetic Proxy endpoint
# Rotating: no sessid — fresh IP per request
# Sticky: sessid present — same IP for all requests sharing the session ID

import requests
import httpx
import asyncio
import time
import random
import uuid
from typing import Optional

MP_USERNAME = "YOURUSERNAME"
MP_PASSWORD = "YOURPASSWORD"
MP_HOST     = "rs.magneticproxy.net"
MP_PORT     = "443"

def build_proxy_url(
    country:    str = "us",
    sticky:     bool = False,
    session_id: Optional[str] = None,
    sesstime:   int = 1800,
    region:     Optional[str] = None,
    city:       Optional[str] = None,
) -> str:
    # Build username string — sessid present = sticky, absent = rotating
    user = f"customer-{MP_USERNAME}-cc-{country}"

    if region:
        user += f"-rg-{region}"
    if city:
        user += f"-city-{city.replace(' ', '_').lower()}"

    if sticky:
        sid = session_id or str(uuid.uuid4()).replace("-", "")[:12]
        user += f"-sessid-{sid}-sesstime-{sesstime}"

    return f"https://{user}:{MP_PASSWORD}@{MP_HOST}:{MP_PORT}"

def rotating_request(url: str, country: str = "us") -> dict:
    # Rotating mode — new residential IP per request
    proxy_url = build_proxy_url(country=country, sticky=False)
    proxies   = {"https": proxy_url, "http": proxy_url}

    time.sleep(random.expovariate(1 / 1.2))  # Poisson delay
    response  = requests.get(url, proxies=proxies, timeout=15)
    return {"url": url, "status": response.status_code, "mode": "rotating"}

def sticky_request(
    url:        str,
    session_id: str,
    country:    str = "us",
    sesstime:   int = 300,
) -> dict:
    # Sticky mode — same residential IP for all requests sharing session_id
    proxy_url = build_proxy_url(
        country=country, sticky=True,
        session_id=session_id, sesstime=sesstime
    )
    proxies  = {"https": proxy_url, "http": proxy_url}

    response = requests.get(url, proxies=proxies, timeout=15)
    return {"url": url, "status": response.status_code, "mode": "sticky",
            "session_id": session_id}

def scrape_catalog(urls: list[str], country: str = "us") -> list[dict]:
    # Catalog scraping — rotating mode, each URL gets a fresh IP
    print(f"Scraping {len(urls)} catalog pages with rotating proxies...")
    results = []
    for url in urls:
        result = rotating_request(url, country)
        results.append(result)
        print(f"  ✓ {url[:60]} — {result['status']}")
    return results

def simulate_checkout_flow(
    product_url:  str,
    cart_url:     str,
    checkout_url: str,
    country:      str = "us",
) -> dict:
    # Checkout flow — sticky mode, all steps share the same residential IP
    # sesstime=300 (5 min) — enough for a checkout, short enough to limit exposure
    session_id = str(uuid.uuid4()).replace("-", "")[:12]

    print(f"\nCheckout flow with sticky session: {session_id}")
    steps = [
        ("product_view",    product_url),
        ("add_to_cart",     cart_url),
        ("checkout_submit", checkout_url),
    ]

    flow_results = []
    for step_name, url in steps:
        result = sticky_request(
            url, session_id=session_id, country=country, sesstime=300
        )
        result["step"] = step_name
        flow_results.append(result)
        print(f"  ✓ {step_name}: {result['status']} (IP consistent via sessid)")

    return {"session_id": session_id, "steps": flow_results}

if __name__ == "__main__":
    # Phase 1: Catalog scraping with rotating proxies
    catalog_urls = [
        "https://ipinfo.io/json",  # Replace with actual target URLs
        "https://ipinfo.io/json",
        "https://ipinfo.io/json",
    ]
    catalog_results = scrape_catalog(catalog_urls)

    # Phase 2: Checkout flow with sticky session
    checkout_result = simulate_checkout_flow(
        product_url  = "https://ipinfo.io/json",
        cart_url     = "https://ipinfo.io/json",
        checkout_url = "https://ipinfo.io/json",
    )

    print(f"\n✓ Catalog: {len(catalog_results)} pages scraped")
    print(f"✓ Checkout: {len(checkout_result['steps'])} steps completed")
    print(f"  Session ID: {checkout_result['session_id']}")

Plug in your Magnetic Proxy credentials from the dashboard and replace the ipinfo.io URLs with your actual targets, the code runs as-is. The catalog phase returns a different IP for each request. The checkout phase returns the same IP across all three steps.

Start testing both modes with code FIRSTPURCHASE for 80% off your first month at magneticproxy.com.

The Detection Risk Difference

Rotating and sticky modes create different behavioral signatures that anti-bot systems evaluate differently.

Rotating mode distributes requests across many IPs. No single IP accumulates a suspicious request volume. The risk is low for scraping workflows but the mode fundamentally cannot maintain state, every request looks like a new user.

Sticky sessions create a different risk profile. An IP that stays assigned for 30 minutes and handles 50 requests during that window looks like an active user, which is fine for a genuine browsing session but unusual if those 50 requests are all API calls or structured data fetches. IP fingerprinting systems that track behavioral pattern detection across time will flag an IP that generates machine-like request patterns even if the IP itself is residential.

The practical rule: sticky sessions are for short, specific workflows, a checkout flow is 5–10 requests, a login-plus-dashboard session is 3–8. These are human-plausible volumes for a single IP. Using sticky sessions for 200 consecutive requests on the same IP undermines the residential IP's trust score for that session.

Both modes draw from the same pool of residential proxies — real IP addresses assigned by ISPs to consumer devices, which is why both modes pass the anti-bot detection that blocks datacenter IPs regardless of session configuration. For a full breakdown of why ISP-assigned IPs behave differently from datacenter IPs, see our guide on what is a residential proxy. (Source: CatProxies, April 2026)

One Plan, Two Tools - Most Pipelines Need Both

The sticky vs rotating proxies question isn't a one-time choice. It's a per-workflow decision that production pipelines make automatically based on what each task requires.

Catalog scraping: rotating. Login sequence: sticky. Rank tracking: rotating. Account creation: sticky. The configuration lives in the username string, the switch between modes is a function parameter, not a plan change or a provider switch.

That's the practical consequence of the same-pool model. When to use sticky proxies and when to use rotating isn't a product decision, it's an architectural one. Build the pipeline to use the right mode for each task, and the residential IP pool handles the rest.

‍