Rotating vs Sticky Proxies: How IP Rotation Actually Works

Some links here are affiliate links — if you buy through them we may earn a commission at no extra cost to you. It never changes what we recommend. Full disclosure.

"Rotating" is the most overloaded word in the proxy market. Providers use it for a gateway that hands out a new IP on every request, for a list of static IPs you cycle through yourself, and for sessions that hold one IP for half an hour and then change. Those behave completely differently, and picking the wrong one is behind a large share of the "my proxies keep getting blocked" problems people blame on proxy quality.

This guide explains the two session models — rotating and sticky — how each works under the hood, which jobs need which, and how to configure them without wasting bandwidth.

The Two Models in One Paragraph

A rotating session gives each request (or each new connection) a different exit IP. A sticky session keeps the same exit IP for a set period, typically from one minute to a few hours, so a sequence of requests looks like one visitor. Rotation spreads load across many addresses; stickiness keeps state — cookies, logins, carts, multi-step flows — consistent. Most serious workloads use both: rotating for independent page fetches, sticky for anything that has to look like a single continuous user.

How Rotation Is Delivered

Gateway (backconnect) rotation

Most residential proxies, mobile proxies and many datacenter plans give you one hostname and port — the gateway. You send every request to it; the provider picks the exit IP from its pool. You never see the list of IPs, and you don't need to.

How the gateway decides when to change IP is controlled by your credentials or port:

• Per request: every HTTP request leaves from a new IP.
• Per connection: a new IP for each new TCP connection, so requests reusing a keep-alive connection share an IP.
• Sticky session: you add a session ID to the username (for example user-session-abc123), and the gateway keeps routing that session ID to the same exit for the configured duration.

List rotation

With static proxies — datacenter, dedicated and ISP proxies — you get a list of IP:port entries, and rotation is your job. Your scraper or tool picks a proxy per request or per task, round-robin or at random, and retires ones that start failing. Every IP is inherently "sticky" for as long as you choose to use it.

Neither approach is better in general. Gateways are simpler and draw from much bigger pools; lists give you control, predictable IPs (useful for allowlisting) and usually flat pricing.

When You Need Rotating Sessions

Rotation fits workloads made of many independent requests where no request depends on the one before:

• Collecting product pages, listings or search results at volume
• Price and availability checks across many URLs
• Crawling public pages for SEO audits or content research
• Any job where the target rate-limits per IP and you want to spread the load

The benefit is simple arithmetic. If a site allows about 60 requests per minute per IP and you need 6,000 per minute, you need traffic spread across at least 100 IPs at any moment. Rotation does that automatically.

When You Need Sticky Sessions

Stickiness fits anything with state:

• Logging in and then browsing as that account
• Multi-step flows: search, then filter, then paginate, then open results
• Checkout or cart testing
• Sites that tie a session cookie to the IP that created it and challenge you if the IP changes mid-session
• Managing social or marketplace accounts, where one account suddenly appearing from ten countries in ten minutes is a red flag

If you rotate during one of these flows, the target sees a single session cookie hopping between unrelated IPs. That's one of the strongest bot signals there is, and it's a common cause of blocks that get wrongly blamed on "bad IPs".

How long should a sticky session be?

As long as the task, and no longer. A pagination run that takes three minutes needs a five-minute session, not a two-hour one. Long sessions on residential or mobile networks have a real cost: the exit device can go offline mid-session, and you've tied a lot of traffic to one IP. Common settings:

• 1–10 minutes: search-and-paginate flows, short multi-step scrapes
• 10–30 minutes: account browsing sessions, cart and checkout testing
• Hours: long account sessions where IP continuity really matters — and where an ISP (static residential) proxy is often the better tool, since it doesn't change at all

ProxyScrape's residential network, for example, supports both per-request rotation and sticky sessions of up to around two hours, with country, state and city targeting.

Rotation and Your Bandwidth Bill

On per-GB plans, rotation itself is free, but what you do with it isn't. Three habits cut costs a lot:

1. Don't rotate on retries blindly. If a request fails because the page itself returned an error, retrying from a new IP just spends more bandwidth. Retry from a new IP only on block signals (403, 429, CAPTCHA pages, empty soft-block pages).
2. Block heavy resources. Images, fonts, video and third-party scripts can be 80–90% of a page's weight. If you only need the HTML or an API response, don't download the rest.
3. Match the tier to the target. Many sites that "need residential" work fine on rotating datacenter IPs. Test cheap first. If bandwidth is the main cost, unlimited bandwidth proxies priced per thread can be cheaper for high-volume jobs.

Rotation Doesn't Fix Everything

Changing IP hides one signal. Modern anti-bot systems look at many more:

• Request rate per session — rotating IPs while hammering the same endpoint ten times a second still looks automated.
• Headers and TLS fingerprint — a Python client presenting a Chrome user agent but a non-browser TLS handshake is easy to spot whatever its IP.
• Behaviour — jumping straight to deep URLs with no referrer, no asset loading and perfectly regular timing.
• Subnet concentration — fifty "different" IPs from the same /24 block look like one source. Count distinct subnets, not just IPs.

If you rotate on every request and still get blocked, the problem is probably one of these, not the proxy pool.

Configuring It in Practice

A typical gateway setup uses the username to control session behaviour. The exact syntax differs by provider, but the pattern is:

# rotating: new IP per request
http://USERNAME:PASSWORD@GATEWAY:PORT

# sticky: same IP while this session id is reused
http://USERNAME-session-job42:PASSWORD@GATEWAY:PORT

# sticky + country targeting
http://USERNAME-country-us-session-job42:PASSWORD@GATEWAY:PORT

In code, create a new session ID per task — one per account, one per pagination run — rather than one per script. For tool-specific setup, see our guides to HTTP proxies, SOCKS5 proxies and ScrapeBox and proxies.

A sticky-session example in Python

The most common mistake in code is creating one session ID for the whole script, so every task shares one IP. Generate one per task instead:

import uuid
import requests

GATEWAY = "GATEWAY:PORT"
USER, PASSWORD = "USERNAME", "PASSWORD"

def session_for_task(country="us"):
    """One sticky IP for the lifetime of one task."""
    sid = uuid.uuid4().hex[:10]
    proxy = f"http://{USER}-country-{country}-session-{sid}:{PASSWORD}@{GATEWAY}"
    s = requests.Session()
    s.proxies = {"http": proxy, "https": proxy}
    return s

def rotating():
    """New IP per request: no session id."""
    proxy = f"http://{USER}:{PASSWORD}@{GATEWAY}"
    return {"http": proxy, "https": proxy}

# Paginate one search on a single IP, then throw the session away
s = session_for_task()
for page in range(1, 6):
    r = s.get(f"https://example.com/search?q=widgets&page={page}", timeout=30)
    print(page, r.status_code)

# Independent product pages: rotate on every request
for url in ["https://example.com/p/1", "https://example.com/p/2"]:
    print(url, requests.get(url, proxies=rotating(), timeout=30).status_code)

Swap the username format for your provider's. The pattern stays the same: one session ID per unit of work, discarded when the work is done.

A Worked Example: Rank Tracking 500 Keywords in 10 Cities

Suppose an agency tracks 500 keywords across 10 cities for a client, daily. That's 5,000 search result pages a day. How should the sessions work?

• Each keyword-and-city check is independent, so rotation between checks is right. There's no reason two different keywords should share an IP.
• Each check may need more than one request, for example the first results page plus page two, or a request that sets location cookies first. Those requests belong to one short sticky session of a minute or two, so the results pages come from the same "visitor".
• City targeting matters more than pool size. A residential IP that actually geolocates to the right city gives far more realistic local results than any number of IPs elsewhere.
• Spread the load over the day. 5,000 checks in ten minutes looks nothing like real users; 5,000 spread over a few hours, with randomised delays, looks far more natural and gets blocked far less.

In practice many teams skip managing this themselves and use a SERP API, which handles rotation, location and parsing and charges per result. Whether that's cheaper than proxies depends on volume; the SEO and SERP tracking guide walks through the trade-off.

Measuring Whether Your Rotation Is Working

Don't judge a proxy setup by feel. Log a few numbers per run and the right settings become obvious:

• Success rate: the share of requests that return the content you wanted, not just HTTP 200. Many blocks return a 200 page that says "verify you are human".
• Block rate by session age: if failures cluster at the start of sessions, the target dislikes the IPs; if they cluster later, your sessions are too long or your request rate within them is too high.
• Unique IPs and unique subnets seen: check the exit IP on a sample of requests (an IP-echo endpoint is enough). If 1,000 requests came from 40 subnets, your effective pool is much smaller than advertised.
• Cost per successful result: bandwidth or plan cost divided by usable results. This is the number to compare between tiers and providers — a cheaper proxy with a 60% success rate can cost more per result than a pricier one at 95%.
• Latency percentiles: the median hides problems; the slowest 5% of requests show unstable exit nodes and long sessions on residential networks.

Run the same small test — a few hundred requests against your real target — whenever you change provider, tier or session settings, and keep the results. It's the fastest way to stop paying for a tier your targets never required.

Quick Decision Guide

Frequently Asked Questions

Is rotating always better for avoiding blocks?

No. Rotating mid-session is a common cause of blocks on sites that bind sessions to IPs. Rotate between independent tasks, stay sticky within them.

Can I get a sticky session on datacenter proxies?

With a static list, every IP is sticky for as long as you keep using it. Datacenter gateways often support session IDs as well.

What happens if my sticky IP goes offline?

On residential and mobile networks, the gateway either assigns a new IP for the same session ID or returns an error, depending on the provider. Build your code to treat that as "start the task again", not as a block.

How many IPs do I really need?

Divide your required request rate by what one IP can safely send to the target, then add headroom. Test that number before buying a pool sized by marketing copy.

Bottom Line

Rotate between independent requests to spread load; stay sticky within anything that has state. Most blocking problems that look like "bad proxies" are really the wrong session model, the wrong request rate, or a fingerprint that gives the client away. Fix those first, and test the cheapest tier that passes before paying for a more expensive one — the approach the whole proxy guide series is built on.

Printed from seo-serps.com — https://seo-serps.com/online-business/rotating-vs-sticky-proxies-how-ip-rotation-actually-works/ — updated November 5, 2026.