Rotating vs static proxies: how rotation works, and when it hurts

Rotating vs static proxies is a question of how long you keep one address. A rotating proxy gives you a different exit IP from a shared pool on each request, or each new connection. A static proxy keeps one IP for as long as you hold it. Rotate when you collect public pages at volume and each request stands on its own. Stay static when the target remembers you: logins, carts, checkouts, and anything that allowlists your IP. Sticky sessions sit between the two: a rotating pool asked to hold one exit for a while.

A common and expensive mistake is buying rotation for a job that needs continuity, then fighting the target for weeks. The sections below are about avoiding that.

#What a rotating proxy is

With a rotating proxy you connect to one gateway address, and the provider picks the exit IP for you from a pool. Each exit is a different address, often on a different network and in a different place. The target sees a crowd of unrelated visitors instead of one busy one.

A detail that trips people up: many gateways choose the exit when a connection opens, not per HTTP request. A client that keeps the connection alive, such as a requests.Session or a browser, can see the same exit for many requests in a row. If you expect a new IP every time and do not get one, check connection reuse before you file a ticket.

Rotation is what residential networks do by default, because the pool is made of consumer devices that come and go anyway.

#What a static proxy is

A static proxy is one address that stays yours: ISP and datacenter proxies are sold this way. Each IP is its own endpoint with its own host, port and credentials, and it does not change for the term you bought. If you hold ten, you have ten fixed identities, and any rotation between them is something you do in your own code.

Static addresses build a history with each target, good or bad. That is the point for account work, and the risk for heavy crawling.

#Sticky sessions: the middle ground

A sticky session is a request to a rotating pool: "keep giving me the same exit for a while". Most providers implement it by letting you put a session identifier in the proxy username or password; every request carrying the same identifier goes out through the same exit until the session lifetime ends or the exit disappears.

Sticky is not static:

• The exit can vanish. On residential, the device behind your exit can go offline mid-session, and you land on a new address with no warning.
• Lifetimes are capped. Every provider limits how long it will hold a sticky exit, and the limit is short next to a static IP's term.
• You cannot allowlist it. Nobody can put a sticky residential exit on a partner's firewall.

Sticky sessions are good for short multi-step flows on a rotating pool, such as paging through one search. For anything measured in days, you want a static IP. On ProxyHive residential, see the options on your order in the dashboard for session control; our static lines need none.

#Rotating vs static proxies compared

#When rotation hurts

Rotation is a tool for making requests look unrelated. When the target needs them to be related, it works against you.

#Logins and account sessions

Platforms bind a login to where it came from. An authenticated session that moves between addresses, networks and countries mid-flow looks like a stolen cookie. Expect re-authentication prompts, "new device" emails, forced password resets and, eventually, locked accounts. For accounts you own, one fixed address per account is the normal setup; the account management use case covers it.

#Carts and checkouts

Shops score checkouts for fraud, and an address change between "add to cart" and "pay" is one of the loudest signals there is. Even for testing your own store, a cart that hops IPs gets flagged.

#Multi-step flows and pagination

Search pagination, form wizards and anything carrying a CSRF token often tie state to the session and sometimes to the address. Rotating mid-flow gets you page one of three, then an error.

#Rate limits

Rotation spreads load across exits, so no single address hits a per-IP limit. It is not permission to send more than a site can take. Our allowed-use policy asks you to respect targets' rate limits, and a crawl heavy enough to degrade a service is treated like a denial-of-service attack whichever proxies carried it.

#When static proxies are the wrong choice

Static proxies fail in the opposite direction:

• Wide crawling. A handful of addresses sending thousands of requests an hour each builds a request history targets notice, and once one is flagged it stays flagged for your term.
• Needing many distinct exits. If a job needs a thousand different addresses, buying a thousand static IPs costs far more than per-GB rotating traffic.
• Very uneven workloads. Per-IP billing charges for the term whether you use the address or not.

For more on matching the line to the job, see residential vs ISP vs datacenter proxies, and for the client-side habits that matter more than either, how to avoid getting blocked when web scraping.

#Rotating a list of static IPs yourself

If you hold several static IPs, you choose the rotation policy, which is often better than leaving it to a gateway. Three policies cover most jobs:

1. Round robin. Each request takes the next address in the list. Even load, predictable.
2. Random. Each request picks any address. Simple, uneven in the short run.
3. Sticky by key. Each account, domain or job always maps to the same address. This is a sticky session you control, with no lifetime and no vanishing exit.

Copy your IPs from the dashboard in the USER:PASS@HOST:PORT format, one per line, into proxies.txt. This Python sketch, using the proxy support in requests, does round robin for general requests and sticky-by-key for accounts:

import hashlib
import itertools

import requests

with open("proxies.txt") as f:
    PROXIES = [f"http://{line.strip()}" for line in f if line.strip()]

round_robin = itertools.cycle(PROXIES)


def fetch(url: str) -> requests.Response:
    proxy = next(round_robin)
    return requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=15)


def proxy_for(account: str) -> str:
    digest = hashlib.sha256(account.encode()).digest()
    return PROXIES[int.from_bytes(digest[:8], "big") % len(PROXIES)]


def fetch_as(account: str, url: str) -> requests.Response:
    proxy = proxy_for(account)
    return requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=15)


for page in range(1, 4):
    print(fetch(f"https://httpbin.org/anything?page={page}").status_code)

print(fetch_as("[email protected]", "https://api.ipify.org?format=json").json())

We ran it against two local authenticating proxies: the three page requests alternated between them, and proxy_for returned the same address for the same account on every call. A hash keeps the mapping stable across restarts without storing anything. The catch is that adding or removing an IP reshuffles some accounts, so for account work keep an explicit account-to-IP table instead.

A production rotator also needs retries on a different address, health checks and backoff on 429 responses. How to rotate proxies in Python builds that out step by step.

#Which ProxyHive line rotates

• Residential is a rotating pool, billed per GB at $5.50/GB to start, with traffic that never expires. It has no location selection today. For session control, see the options on your order in the dashboard.
• ISP and datacenter are static per-IP endpoints. Each IP has its own host, port and credentials, stays the same for your term, and needs no session setting. Both sell from one IP, ISP from $3.20/IP a month and datacenter from $3.20/IP, and ISP is ordered by country, region, city and carrier.

Many teams run both: residential for crawling, a few static ISP addresses for accounts and allowlisted APIs. What is an ISP proxy explains the static side in more depth.

#A five-question checklist

1. Does the target need to recognise you between requests? Yes: static.
2. Does a partner need to allowlist your address? Yes: static.
3. Does the job need hundreds or thousands of distinct exits? Yes: rotating.
4. Is each request independent and public? Yes: rotating is usually cheaper and simpler.
5. Do you need a short multi-step flow on a rotating pool? Use a sticky session where your order offers one, or sticky-by-key across your own static IPs.