Rotating vs Static Proxies: When a Fixed IP Wins

Static wins when the far side must recognize your address; rotating wins when it must not. How to tell which job you have, and how to run both.

The rotating versus static choice fails in opposite directions, which is why people get it wrong twice. Put a login job on a rotating pool and it logs itself out; put a crawl on a static address and the address wears out in a day. Both look like "the proxies are bad" from inside the job. The decision underneath is simpler than the symptoms: does anything on the far side of the connection need to recognize your address? If yes, static. If it must not, rotating. This guide is about telling which job you have, what each choice costs, and the setup that runs both from one process.

The difference in one sentence

A static proxy is an address that is yours until you replace it. A rotating proxy is an address that belongs to a pool, lent to you for one connection (one HTTPS tunnel or SOCKS5 connection, or a single plain-HTTP request).

Everything else follows from ownership. Ownership is what lets you put a static address on the firewall of a partner, warm its reputation with one target over weeks, and see the same address in every log line when something breaks. Lack of ownership is what lets a rotating pool absorb a per-address rate limit across hundreds of exits, and what stops any one of them being worth anything to you individually. How the rotating side actually assigns exits, and the IPv4 scarcity that shapes it, is covered in IPv4 rotating proxies; this guide takes the mechanism as read and stays on the decision.

How each wrong choice announces itself

The two mistakes have different signatures, and reading them correctly saves a plan change in the wrong direction.

A crawl on a static address that wanted a pool degrades with time rather than with URL. The first hour is clean, 429s and CAPTCHA pages climb through the day, and an idle night restores the address, because the target is scoring volume per address and yours is the only one it sees. The worker that has been up longest fails most. Buying more static addresses helps in proportion to the count; moving to a pool removes the ceiling altogether.

A conversation on a rotating pool that wanted continuity fails by step rather than by time. Every request returns 200, and the damage is a login that has to be repeated, a form that resets, or a result set that hands back its first page again several requests in. Nothing in the proxy layer reports it, because nothing in the proxy layer went wrong. The confirmation is to replay the flow through a fixed address; if it completes, rotation was the cause, and the fix is a sticky session or a static address depending on how long the conversation lasts.

Where static wins

Whitelisted access. A partner API, a staging environment belonging to a client, a firewall that admits a list of addresses: these need an address you can hand over and that will still be true next month. A pool exit cannot go on anyone's whitelist because you will never see it again. This is the one case with no rotating substitute at all.

Identity that outlives a session. An account you operate for weeks, a storefront you monitor as the same customer, a dashboard you log into every morning: a target that keeps history per address builds a picture of you, and you want that picture to be boring. Change the address daily and the picture is of an account that travels between networks, which is what a compromised account looks like. Continuity for minutes is a sticky session on a rotating plan and belongs in sticky vs rotating proxies; continuity for days is a static address, and the boundary between the two is roughly the 30 minute ceiling on a datacenter session pin.

Reputation you build and keep. Some targets score addresses by their own observed history rather than by public classification, and an address that has behaved for a month gets latitude a stranger does not. That latitude belongs to the address. On a rotating pool it evaporates the moment your connection closes, and the next customer inherits whatever you earned.

Deterministic debugging. One address per worker means one address in the logs of the target, in your logs and in the logs of the partner, so a "we saw abuse from X" email maps to a worker in seconds. Rotating jobs can be debugged, but every request needs the exit it left from recorded first, and the section on running both covers that.

Where rotating wins

Volume against a per-address limit. A target that tolerates a few hundred requests an hour from one address will tolerate the same from each of a hundred addresses. Static plans can do this too, by cycling your own list, but the ceiling is the number of addresses you bought; the ceiling of a pool is the pool. How to rotate proxy IPs shows the client-side cycling pattern for the static case and how to size the rate.

Breadth over depth. Price sampling across storefronts, availability checks across a catalog, link checks across a site: each request is its own tiny job and there is nothing between them to preserve. Paying for an owned address to do stateless work is paying for a property you are not using.

Disposable identity. Discovery crawls against targets that flag hosting ranges quickly burn addresses. On a static plan a burned address is your problem; the Refresh IP action replaces it, but that is a transplant rather than a rotation, and refreshing on a schedule is the most expensive way to rotate there is. On a pool, a burned exit is the problem of the pool and the next connection leaves from another.

Bursty workloads. A job that runs hard for an hour a day and idles otherwise buys idle capacity on a per-address plan. A metered rotating plan bills the bytes and nothing else.

Three questions that sort a job

Will anyone put this address on a list? If a partner, a client or a firewall needs to know the address, it is static, full stop.
Does the target need to recognize you tomorrow? Recognition for minutes is a sticky session on a rotating plan; recognition across days is static.
Is the address the thing that wears out? If your failure mode is a per-address rate limit or a burned address, the job wants a pool. If your failure mode is a lost login or a reset cart, it wants continuity.

Answer all three and the plan chooses itself. A job that answers differently at different steps is the hybrid below, not a contradiction.

The billing model changes the engineering

Dedicated datacenter plans are priced per address per month and carry no transfer meter. Shared datacenter plans are priced by address count too but carry a transfer allowance, so retries are not free there. Rotating Datacenter bills per gigabyte transferred, and Rotating Unmetered drops the byte meter and prices concurrent connections instead; both draw the same pool, so choosing between them is choosing a meter rather than a grade of address. Those are different things to optimize, and the wrong intuition carried across is what surprises people at the invoice.

On a per-address plan with no meter, a failed request and its retry cost nothing extra, and the number that matters is how many addresses a job needs to stay under the per-address tolerance of the target, which how many proxies do I need works out. On a per-gigabyte plan, every retry bills the bytes again, so payload size and retry caps are the levers, and a job that pulls large pages or media can cost more rotating than static even though the address count looked cheap. On a connection-priced plan, the lever is how many connections you keep open, counting idle HTTPS tunnels parked in a client's pool, since each holds a slot for its whole life. The models are compared in proxy pricing models, and the current figures are on the dedicated, Rotating Datacenter and Rotating Unmetered pricing pages rather than here, because a price typed into an article is stale the day the ladder moves.

The hybrid: static for the conversation, rotating for the crawl

Most pipelines have both kinds of step, and nothing forces one plan per process. Route by what the step needs:

import requests

# one owned address, copied from the Proxies page
STATIC = "http://USERNAME:PASSWORD@203.0.113.10:PORT"
# the pool
ROTATING = "http://USERNAME:PASSWORD@gw-rotating_datacenter.node4.io:8083"

def crawl(url):
    # stateless: fresh connection, fresh exit
    return requests.get(url, proxies={"http": ROTATING, "https": ROTATING},
                        headers={"Connection": "close"}, timeout=30)

account = requests.Session()
account.proxies = {"http": STATIC, "https": STATIC}
account.post("https://target.example/login", data=creds)

for url in discover_with(crawl):      # rotating: find the pages
    row = account.get(url)            # static: read them as the account

The pattern generalizes: authenticate and hold state on the owned address, discover and sample on the pool. Log the exit for each rotating request (an api.ipify.org check at worker start is the cheap version) so a complaint about an address can still be traced to a job. If the static side needs more than one address, cycle them in code rather than buying a rotating plan for that half; if the rotating side turns out to be the whole job, drop the static half rather than paying for an address that only holds a login nobody reads.

Where static loses

An owned address is a commitment in both directions. It wears out against a single hard target, and when it does you replace it, which means updating every whitelist, config file and partner firewall that had the old one, so the addresses you hand to other people should be the ones you never intend to refresh. It is also a datacenter address, and a target that scores by address type gives it the same score it gives a pool exit; ownership buys continuity, not a different classification, and the way out of that is residential exits, which are neither static nor yours to keep. And static capacity is fixed: bought ahead, idle when the job idles, and only as parallel as the address count.

Which to buy

If the job needs to be recognized, start static. Dedicated datacenter proxies are the owned, unmetered form; shared datacenter proxies are the cheaper form for work that does not need an address to itself. Registering your source address instead of sending a password works on both, and IP whitelisting best practices covers the operational side. If the job needs to be forgotten, start with the smallest rotating plan and run the ten-connection loop from the rotating guide against your real target before buying volume.

The free tier is static shared datacenter (3 free shared proxies with 1 GB/month bandwidth and 10 concurrent threads), so it is enough to prototype the static half of a hybrid and nothing on the rotating half, which it cannot reach.