Rotating Datacenter Proxies, Priced per GB or Unmetered
One endpoint, a different exit IP on every request. You connect to a single gateway address and the rotation happens behind it, so there is no IP list to manage, no rotation logic to write, and nothing to update when the pool changes. There are two ways to pay for it: per gigabyte, which is the tier most people start on, or Rotating Unmetered, which removes the byte meter and charges for how many connections you hold open at once instead. Three separate things get called rotation and they are not interchangeable: a gateway that picks a new address per request, which is this product; a sticky session that deliberately holds one address across a login or a checkout; and an API call that permanently swaps the address on a static proxy you already own. The first two are chosen per request on the same endpoint and the same credential. The third changes your inventory.
Rotating datacenter or rotating residential?
Worth settling first, because "rotating proxies" is used for both. This product rotates through datacenter addresses on IP blocks we own: fast, cheap per gigabyte, and the right choice when the target does not specifically reject hosting ranges. If your target blocks datacenter IPs outright, you want rotating residential instead: our residential product rotates by default on the same one-endpoint model, at a higher price per gigabyte. Same gateway design, different pool.
The life of a rotated request
Every request makes the same journey: your client connects to the tier's gateway hostname, the gateway authenticates the username, selects an address from the owned pool (honoring a country segment if you set one, or a pinned session if you set that) and relays your request through the node that egresses from the selected address. On the next request, the selection runs again. The point of the design is that the moving parts live on our side of the line: your code holds one hostname, one port and one credential, while pool changes, address replacement and selection logic all happen behind the gateway without a deploy on your end.
Per-request rotation or sticky sessions
By default each request leaves from a different address. When you need continuity (a login, a cart, a multi-step flow), add a session identifier to the username and the same exit IP is held for that session. Both behaviors use the same endpoint and the same credential.
Neither of those is the same thing as asking the API to swap an address on a static proxy, which is a change to what you own rather than a per-request choice: compare a rotation API with a rotating gateway.
Three tiers, same mechanism
Rotating Premium draws from dedicated IPs; Rotating Shared draws from addresses shared with up to 5 users at a materially lower per-gigabyte price. Both are billed by bandwidth rather than per proxy, which suits bursty workloads where a fixed monthly proxy count would be mostly idle. Rotating Unmetered is the third: the same gateway and the same rotation, with no bandwidth meter at all, priced by how many connections you hold open at once.
Country targeting
Add a country segment to the username to constrain exits to a market. Because rotation runs on IP blocks node4 owns, the pool composition is known rather than inherited from an upstream reseller.
What rotation does and does not fix
Rotation defeats one specific defense: per-IP accounting. Rate limits, per-address request caps and single-IP bans stop mattering when every request arrives from a different address. It does not defeat classification: every address in this pool is a datacenter address, and a target that refuses hosting ranges will refuse all of them, rotated or not; that job needs the residential product. Nor does it defeat identity tracking above the IP layer: cookies, headers and TLS fingerprints travel with your client whatever the exit is, and a target correlating on those will connect your rotated requests regardless. Buy rotation for breadth of addresses, not for invisibility; nothing sold under this name, by anyone, provides that.
A pool you can reason about
Because rotation draws on blocks node4 owns (the live owned-IP count is at the top of this page), the pool has a property worth naming: known composition. Nothing silently swaps ranges in and out underneath us, and every address in it has only ever been ours. The honest flip side is that an owned pool is a finite pool: hammer a single target hard enough for long enough and it will see addresses again. For most workloads that is irrelevant; for adversarial ones it is the signal to slow down, spread across targets, or move that workload to residential, where the partner pool is orders of magnitude larger.
Session mechanics, precisely
A session is declared, not configured: append a session segment to your username and every request carrying that id exits from the same address for up to 30 minutes; drop it and you are back to per-request rotation, with no state to clean up. The 30 minutes run from when the pin is first assigned, not from your most recent request, so a busy session does not extend its own window. Work that needs to outlive it should either mint a fresh session id and carry on, or be built to tolerate the exit changing at the boundary. Pinning is shared between protocols: the HTTP and SOCKS5 listeners consult one session store, so a flow that starts on one can continue on the other without changing exit. Use one session number per logical identity (one login, one cart, one crawl of a stateful site), and when a session's exit has worn out its welcome with the target, retire the number and mint a new one rather than trying to rehabilitate it.
Protocols
HTTP(S) and SOCKS5 on the same credential. Sticky sessions carry across protocols: an exit pinned over HTTP stays pinned over SOCKS5, because both listeners share one session store.
Choosing a tier and estimating cost
Premium draws from dedicated addresses; Shared draws from addresses carrying up to 5 users, at a lower per-gigabyte price. Because both are metered, the way to predict your bill is empirical: buy the smallest Shared tier, run a bounded, representative slice of the workload, and read the gigabytes consumed off the dashboard's usage page. That gives you cost per unit of work, and it scales linearly from there. Move to Premium when shared occupancy shows up in your results (more challenges than your own request rate explains), and move to residential when the target rejects hosting ranges wholesale. Bandwidth is metered in both directions; refused connections transfer no bytes and therefore bill nothing.
If the workload moves enough data that a per-gigabyte bill is the wrong shape, dedicated datacenter proxies are unmetered and billed per proxy instead: compare unmetered dedicated against per-GB rotation.
Pricing
Rotating Premium
Auto-rotating premium datacenter proxies with dedicated IPs, billed by bandwidth usage. Per-request rotation by default, or pin one exit with a session id
| Bandwidth | Price per GB | Total | Discount |
|---|---|---|---|
| 10 GB | $0.75/GB | $7.50 /mo | - |
| 25 GBPopular | $0.69/GB | $17.25 /mo | Save 8% |
| 50 GB | $0.62/GB | $31.00 /mo | Save 17% |
| 100 GB | $0.56/GB | $56.00 /mo | Save 25% |
| 250 GB | $0.49/GB | $122.50 /mo | Save 35% |
| 500 GB | $0.44/GB | $220.00 /mo | Save 41% |
| 1 TB | $0.39/GB | $390.00 /mo | Save 48% |
- Bandwidth
- Per GB pricing
- Threads
- Unlimited
- Protocols
- HTTP(S) / SOCKS5
- Sessions
- Per request, or sticky up to 30 min
Rotating Shared
Auto-rotating shared proxies (up to 5 users per IP), billed by bandwidth usage. Per-request rotation by default, or pin one exit with a session id
| Bandwidth | Price per GB | Total | Discount |
|---|---|---|---|
| 10 GB | $0.59/GB | $5.90 /mo | - |
| 25 GB | $0.52/GB | $13.00 /mo | Save 12% |
| 50 GB | $0.47/GB | $23.50 /mo | Save 20% |
| 100 GBPopular | $0.42/GB | $42.00 /mo | Save 29% |
| 250 GB | $0.37/GB | $92.50 /mo | Save 37% |
| 500 GB | $0.33/GB | $165.00 /mo | Save 44% |
| 1 TB | $0.29/GB | $290.00 /mo | Save 51% |
- Bandwidth
- Per GB pricing
- Threads
- Unlimited
- Protocols
- HTTP(S) / SOCKS5
- Sessions
- Per request, or sticky up to 30 min
Rotating Unmetered
Rotating datacenter proxies with no bandwidth meter, priced by how many connections you run at once rather than how many bytes you move. Per-request rotation by default, or pin one exit with a session id
| # of Connections | Price per Connection | Total | Discount |
|---|---|---|---|
| 250 connections | $0.116 | $29.00 /mo | - |
| 600 connections | $0.098 | $59.00 /mo | Save 15% |
| 1,200 connectionsPopular | $0.082 | $99.00 /mo | Save 29% |
| 4,000 connections | $0.062 | $249.00 /mo | Save 46% |
- Bandwidth
- Unlimited
- Threads
- 250 to 4,000
- Protocols
- HTTP(S) / SOCKS5
- Sessions
- Per request, or sticky up to 30 min
Connection details
Premium uses gw-rotating_premium.node4.io on ports 8081 and 1081. One endpoint per tier; the rotation happens behind it.
Code examples
# A different exit IP on every request
for i in 1 2 3; do
curl -s -x http://USER:PASS@gw-rotating_shared.node4.io:8083 https://api.ipify.org
echo
done
# Hold one exit IP for a multi-step flow
curl -x http://USER-session-482913:PASS@gw-rotating_shared.node4.io:8083 \
https://api.ipify.org
# Premium tier over SOCKS5
curl --socks5-hostname USER:PASS@gw-rotating_premium.node4.io:1081 https://api.ipify.orgpip install requests[socks]import requests
HOST = "gw-rotating_shared.node4.io"
USER, PASS = "user-42-abc123", "your-password"
# Per-request rotation: no IP list to manage
rotating = {"https": f"http://{USER}:{PASS}@{HOST}:8083"}
for _ in range(5):
print(requests.get("https://api.ipify.org", proxies=rotating).text)
# Sticky: same exit for a login or cart flow
sticky = {"https": f"http://{USER}-session-482913:{PASS}@{HOST}:8083"}
with requests.Session() as s:
s.get("https://example.com/login", proxies=sticky)
s.get("https://example.com/account", proxies=sticky)npm install https-proxy-agentimport { HttpsProxyAgent } from "https-proxy-agent";
const base = "gw-rotating_shared.node4.io:8083";
const agent = new HttpsProxyAgent(`http://USER:PASS@${base}`);
for (let i = 0; i < 5; i++) {
const res = await fetch("https://api.ipify.org", { agent });
console.log(await res.text()); // a different IP each time
}How it compares
| Feature | This page | Datacenter | Residential |
|---|---|---|---|
| IP changes | Every request, or sticky | Fixed | Every request, or sticky |
| Endpoints to manage | One | One per proxy | One |
| IP origin | IP blocks we own | IP blocks we own | Partner network |
| Billing | Per GB | Per proxy / month | Per GB |
| Geo targeting | Country | Location of the block | Country, state, city |
| Entry price | $0.59/GB at 10 GB, $0.29 at 1 TB | $1.49/proxy at 5, $0.75 at 1,000 | $2.49/GB at 3 GB, $0.49 at 5 TB |
| Best for | Bursty work needing fresh IPs | Sustained volume | Hosting-blocked targets |
What people use these for
Search and marketplace scraping
Per-request rotation spreads load across many addresses without you writing rotation logic or maintaining a proxy list.
Bursty or scheduled jobs
Per-GB billing suits workloads that run hard for an hour a day. A fixed monthly proxy count would sit idle the rest of the time.
Multi-step flows
Add a session id where continuity matters (a login, a cart, a paginated result set) and drop it again when it does not.
Availability and uptime checks
Repeated checks from constantly changing addresses avoid tripping per-IP rate limits on the target.
High-concurrency crawls
Rotation and concurrency are separate dials. The gateway varies the exit address; how many requests you keep in flight stays yours to set. On the per-GB tiers that number is unconstrained, and on Rotating Unmetered it is precisely the thing you are buying.
Frequently asked questions
How often does the IP change?
On every request by default. Add a session identifier to hold one exit IP instead, for up to 30 minutes measured from when the pin is first assigned.
What is the difference between rotating and residential?
Rotating proxies rotate through datacenter IPs that node4 owns: fast, cheap per gigabyte, and fine wherever datacenter ranges are accepted. Residential rotates through real consumer connections, which is what you need when datacenter ranges are blocked.
Do I need to manage an IP list?
No. You connect to one gateway hostname and port; selection happens behind it.
Is bandwidth shared between the rotating tiers?
No. Each plan has its own allowance and its own endpoint. Rotating Unmetered has no bandwidth allowance to share in the first place; what it caps is concurrent connections.
Do you offer rotating proxies with unlimited bandwidth?
Yes. Rotating Unmetered is a rotating datacenter product with unlimited bandwidth, priced by the number of connections you hold open at once instead of by the gigabyte. It is worth knowing why that is unusual, because it tells you when to choose it. Rotation is metered almost everywhere for a structural reason: a gateway gives you access to a shared pool rather than an address of your own, so traffic is the obvious thing to charge for. We can charge for concurrency instead because these exits are datacenter addresses on blocks we own, so the bytes are not bought from a supplier by the gigabyte, which is also why you should stay skeptical of an unmetered residential offer. What you give up is a ceiling on simultaneous connections, and on a bursty workload you are sized by the burst rather than the average. If your volume is modest and your concurrency is low, the per-GB rotating tiers are still cheaper and remain on sale. The full comparison, including where each one wins, is in unmetered billing versus per GB.
How many concurrent connections can I run?
On the per-GB tiers, Rotating Premium and Rotating Shared, nothing caps how many connections you hold open; the practical ceiling is what your client and the target will sustain, behind a per-source-IP safety brake that no ordinary workload reaches. Rotating Unmetered is the deliberate exception, because concurrency is the thing you are buying there: the rung you pick is a ceiling the gateway enforces rather than a threshold that bills extra, and with no byte meter behind it there is no overage to run up. Size it by the burst rather than the average, since a job that opens many connections briefly needs a larger rung than its mean would suggest.
Does rotating help if the site already blocks datacenter IPs?
No, and we would rather tell you before you pay than after. Rotation changes which address you arrive from, not what kind of address it is. A target that classifies hosting ranges will classify every exit in this pool the same way. That workload belongs on the residential product, which rotates through consumer connections on the same one-endpoint design. Rotating datacenter is for targets that accept hosting traffic but enforce per-IP limits on it.
Can I use IP whitelist authentication on the gateway?
On the rotating gateways, yes: register the address and connect with no credentials for an untargeted exit, or send the username with an EMPTY password to keep country targeting and session pinning, which are declared in the username on every connection. The static datacenter and shared products, where there is nothing to declare per request, offer IP whitelisting the same way. The residential gateway accepts it too, with no halfway option: send nothing at all for an untargeted exit, or use credentials when you need targeting.
Which countries can I rotate through?
The pool is our owned blocks, which currently sit in the United States, Italy and Spain, so a country segment can constrain exits to any of those markets. If your workload needs other geographies, that is residential territory (170+ countries with state and city targeting) rather than something to force out of a datacenter pool.
Does rotation work for logged-in or multi-step flows?
Yes, with a session. Per-request rotation would present a different address on every step, which stateful sites reasonably treat as suspicious; pinning a session id holds one exit for up to 30 minutes instead, which covers most flows; a longer one should mint a fresh session id and carry on. The practical pattern is rotation for discovery (search pages, listings, availability checks) and a session per login, checkout or paginated read, all through the same endpoint and credential, chosen per request by the username.
What does a burned exit cost me here?
Very little, which is much of the product's point. In rotation, a target blocking one address affects only the requests that happen to land on it, and the retry lands elsewhere. In a session, retire the session id and continue on a fresh exit. Compare a static allocation, where a burned address is a decision to make; here it is a retry. The exception is a target that has turned against hosting ranges as a class; no amount of rotation within a datacenter pool recovers from that.
Is there anything to install or configure?
No software, no IP lists, no rotation timers. Anything that can speak to an HTTP or SOCKS5 proxy (cURL, a scraping framework, a headless browser, an HTTP library) points at the gateway hostname and port with your credential and inherits rotation immediately. The code samples below are complete working configurations, not abbreviations.
Guides for Rotating Datacenter Proxies, Priced per GB or Unmetered
Setup, targeting and troubleshooting, written for people already running this in production.
- How IP rotation works, mechanism by mechanism
- The state that breaks when the exit IP changes
- Reading the country header to verify targeting
- Unmetered rotating versus per-GB, and when each one wins
- Rotation policy, cURL and Python, session rules
- Pinning one exit for a multi-step flow
- Wiring a gateway into a production pipeline
- Sizing a rotating pool against a target's tolerance
- Rotating proxies inside a Scrapy crawl
- Fixing 407 Proxy Authentication Required
- Reading a proxy error code before blaming the pool
- What the usage numbers do and do not measure
- What the difference between HTTP and SOCKS5 buys you
- Buying with Bitcoin, and what SOCKS5 will not carry
- SOCKS5 from Axios, and the agent it needs