IPv4 Rotating Proxies: How They Work and How to Use One
Nearly every rotating pool sold for scraping is IPv4, which shapes how targets ban, how pools are metered, and how to test one. cURL and Python included.
An IPv4 rotating proxy is one gateway address that sends each new connection out through a different IPv4 exit from a pool. Node4's rotating pools are IPv4 only, and so are most pools sold for general scraping, because the targets people scrape answer on IPv4 and score IPv4 behavior. "IPv4" on a plan card therefore describes the market rather than distinguishing a vendor. What matters more is how the scarcity of IPv4 addresses shapes the product: pools are shared, targets ban by subnet, and exits repeat. This guide explains those three facts, shows how to test a pool with cURL and Python before you build on it, and ends with how to choose between the two rotating plans.
What an IPv4 rotating proxy is
Your code points at one hostname and one port. Behind it, a gateway holds a pool of IPv4 addresses and, each time your client opens a connection, picks one to send that connection out through. The target sees the exit address, not the gateway and not you. Open a new connection and the gateway picks again.
That is the whole product: a fixed entry point and a variable exit. Everything a vendor adds (country selection, session pinning, metering, dashboards) is a knob on that one mechanism. The rest of this guide is about the mechanism and its knobs; the question of whether your workload wants a variable exit at all, or a fixed address you keep, is rotating vs static proxies.
Why the address family shapes everything else
There are roughly four billion IPv4 addresses and the useful ones were handed out long ago. Every IPv4 address a proxy vendor operates was bought, leased or inherited, and it carries a history. Three consequences follow, and they explain most of what you will observe from a rotating pool.
Pools are shared. No vendor can afford to give each customer a private slice of scarce addresses on a rotating plan, so the same exits serve many customers. An address that comes to you clean may have been used against your target by someone else an hour ago. This is the fact behind the observation that a fresh exit is sometimes already rate limited, and it is why a rotating datacenter pool is budget infrastructure rather than a way to become a stranger to the target.
Targets ban by subnet, not by address. Because addresses are allocated in blocks, a target that sees abuse from three addresses in one /24 will often score the whole /24, which is 256 addresses. A pool of a thousand exits inside four /24s is, to a subnet-scoring target, a pool of four. When you compare vendors, the count that predicts survival is distinct /24s and distinct hosting networks, not raw addresses, and the subnet calculator will show you how a sample of exits actually groups. Take fifty exits from the loop below and count the prefixes yourself.
Rotation happens per connection, and exits repeat. With a finite pool and no memory of what you were given last, the gateway can legitimately hand you the same address twice in a row. A rotation test that asserts "every request differs from the last" will fail against a working pool. Assert spread across a sample instead.
There is no shortcut through a different address family either. The targets you scrape are reachable on IPv4, their defenses are tuned for IPv4 behavior, and Node4's pools contain IPv4 addresses only.
How the gateway assigns an exit
The unit of rotation is the tunnel. For an HTTPS target the client sends one CONNECT, the gateway picks an exit for that tunnel, and every request the client then sends down it leaves through that exit; a SOCKS5 connection works the same way. A modern HTTP client keeps connections alive by default and sends many requests down each one, so if a job appears to rotate far less than the pool size suggests, connection reuse is the first thing to check, and a Connection: close header or a fresh client per request is the fix. The one place this does not apply is a plain http:// target, where the gateway proxies each request individually and picks an exit per request even on a reused connection. How to rotate proxy IPs sets this mechanism against the alternative of cycling static addresses in your own code, and shows how to size the rotation rate against the tolerance of a target.
The one exception to per-connection selection is a session pin: a -session-<id> segment in the username asks the gateway to keep resolving to the same exit for that id, for up to 30 minutes from first assignment on the rotating datacenter gateway. Whether a job wants that is a decision about the target rather than the gateway, and sticky vs rotating proxies is that decision.
cURL: prove the pool rotates before you build on it
The credential comes from the Proxies page of your dashboard; the connection builder will assemble the string if you would rather not type it. Ten connections, each closed after one request, printing the exit each saw:
for i in $(seq 1 10); do
curl -s -H "Connection: close" \
-x http://USERNAME:PASSWORD@gw-rotating_datacenter.node4.io:8083 \
https://api.ipify.org
echo
done | sort | uniq -c | sort -rnA healthy result is several distinct addresses with small counts, and a repeat or two is normal. One address with a count of ten cannot be connection reuse here, because each curl is its own process and its own connection; it means a session segment is stuck in the username. No output and a 407 means the credential is wrong, and fixing 407 Proxy Authentication Required is the page for that.
Country selection on the rotating datacenter gateway is a -country-<cc> segment in the username:
curl -s -H "Connection: close" \
-x http://USERNAME-country-us:PASSWORD@gw-rotating_datacenter.node4.io:8083 \
https://api.ipify.orgOne behavior to know and verify: on the rotating datacenter gateway, a country with no exit in the pool is refused with a 502 whose body explains that the request was refused rather than served from another country, and tells you to check the code or drop the segment. That matches the residential gateway, which also refuses a location it cannot serve. The rotating gateway also sets an X-Node4-Country header (honored, unavailable or none) on every refusal and on plain-HTTP responses. A successful HTTPS tunnel and a SOCKS5 connection carry no such header, and a misspelled targeting key fails authentication with a 407 rather than running untargeted, so for HTTPS work check the exit itself rather than assuming the segment was honored; verifying a proxy's location covers the checks that catch the rest. The residential grammar, which also carries state and city, is in country and city targeting.
If you whitelisted your source address instead of using a password, the username still carries the segments: send it with an empty password and the country and session targeting is kept without the secret.
Python: the stateless shape and the stateful shape
Two shapes cover nearly every job, and the common mistake is using the second for the first.
import requests
GW = "gw-rotating_datacenter.node4.io:8083"
def proxies(username="USERNAME"):
url = f"http://{username}:PASSWORD@{GW}"
return {"http": url, "https": url}
# Stateless fetches: no Session object, so no cookie jar and no reused
# connection. Every call gets a fresh connection and therefore a fresh exit.
for url in urls:
r = requests.get(url, proxies=proxies(), timeout=30,
headers={"Connection": "close"})
handle(r)
# One conversation that must stay on one exit: a Session object with a
# session segment, so cookies and exit travel together.
s = requests.Session()
s.proxies = proxies("USERNAME-session-order91ab")
s.post("https://target.example/login", data=creds)
page = s.get("https://target.example/orders")requests.Session is the right tool exactly when you want continuity, and the wrong default for a crawl, because it pools connections and carries cookies, which together turn a rotating plan into a single-exit plan without telling you. Scrapy users get the same split in proxy middleware, where retries and session assignment belong in one place instead of every spider.
Rotation policy: three that work and one that does not
Per connection is the default and the right choice for stateless volume. On failure is the refinement worth building: keep the connection you have while it succeeds, and open a fresh one when a request draws a 403, 429 or a CAPTCHA page, which rotates only when there is a reason to and keeps your traffic looking like fewer visitors. Pinned is the session segment above, for conversations. The one that does not work is rotating as fast as possible on principle: with cookies or a login in play, one visitor arriving from a hundred networks in an hour is a stronger signal than any single address, and on a per-gigabyte plan the churn buys nothing.
One thing the gateway cannot do for you: for HTTPS it relays an encrypted tunnel between your client and the target, so it never sees the status codes the target returns. Your 403 and 429 counters live in your code, per exit, and rotate-on-failure is built from them. The analytics page of the dashboard shows what the gateway can observe, which is request volume and transfer; rotating traffic is not broken out by exit country there, because a gateway has no single one.
Where an IPv4 rotating datacenter proxy loses
Rotation changes the network address and nothing else. A target that classifies by address type sees a hosting range before and after every rotation, and no pool size or rate moves that; the fix is a different kind of address, which is what residential proxies are for. A target that fingerprints the client sees the same TLS handshake, header order and browser signature from every exit, and the request fingerprint tool will show you what yours looks like before you blame the pool. And a target that has already rate limited a shared exit was not defeated by your rotating onto it; it was defeated when the next customer rotated onto it too, which is the shared-pool trade you accepted for the price.
In short, a rotating datacenter pool is the right tool for volume against targets with ordinary defenses, and the wrong tool against a target that has decided hosting ranges are not customers. Run the loop above against your real target before buying volume.
Which rotating plan
Two products draw on the rotating pool, and what separates them is the meter. Rotating Datacenter is billed by transfer, so bytes per request is the number that decides your bill. Rotating Unmetered is priced by the number of connections you hold open at once and has no byte meter at all, which inverts the economics: on the metered product you save by fetching less, on the connection-priced one you save by keeping fewer requests in flight, and unlimited bandwidth on Rotating Unmetered versus per GB works through which wins for a given job. Pay by the gigabyte if you use a little, by concurrency if you use a lot; that is the whole choice.
What the choice is not is a choice of addresses. Both products rotate through one pool of exits in the US, Italy and Spain, so neither buys you cleaner or more diverse networks than the other, and a test of rotation behavior on one is a test of the other. Country targeting, session pinning and the headers described above work the same way on both. Current prices are on the Rotating Datacenter and Rotating Unmetered pricing pages, and the rotating proxies page lists what each includes. On Rotating Datacenter, per-plan thread figures are fair-use guidance rather than enforced ceilings, and the only enforced brake is a very high per-source-address connection cap. On Rotating Unmetered the connection count is what you buy, so the gateway enforces it as a ceiling: size the plan for your burst, not your average.
The free tier is static shared datacenter and cannot reach the rotating gateway, so it will not evaluate anything on this page; prototype against the smallest rotating plan instead.