Rotating Proxies with Unlimited Bandwidth vs Per-GB

Rotating Unmetered charges for concurrent connections instead of gigabytes. How the two rotating plans bill, and a worked way to pick between them.

Node4 sells rotating proxies two ways. Rotating Datacenter is billed per gigabyte against a monthly allowance. Rotating Unmetered has unlimited bandwidth and is priced by concurrent connections, the number of connections you can hold open at the same time. Both draw on the same pool of datacenter exits in the US, Italy and Spain, with the same rotation behavior and the same sticky sessions, so the choice between them is a choice of meter only: pay by the gigabyte if you move a little data, by concurrency if you move a lot.

The two meters side by side

Current prices for both are on the pricing page.

A per-gigabyte plan charges for traffic: the address is nearly free and the data crossing it is what costs. A per-connection plan charges for capacity: you rent the right to keep a certain number of requests in flight, and whether each pulls two kilobytes or two megabytes does not change the price. A plan sized for a given number of connections refuses the next one while that many are open; it does not slow you down and it does not bill you at some byte threshold. What counts as open depends on the protocol: an HTTPS tunnel or a SOCKS5 connection holds a slot for as long as your client keeps it open, even when idle, while a plain-HTTP request holds one only while it runs. Close pooled HTTPS connections you are not using, or size the client's pool to the plan.

Dedicated datacenter proxies, for completeness, charge per address, one customer per IP for a month, and dedicated datacenter is also unmetered.

Which one is cheaper for your job

The decision turns on bytes per request and how much of the work runs at once.

Many small requests. API polling, price checks, availability lookups, status pages: each response is a few kilobytes, and a hundred thousand of them might total a couple of gigabytes. Per-GB is cheap here, and paying for concurrency you are not using would cost more. Per-GB wins.

Large responses. Full page HTML with assets, file downloads, media, anything where one response is measured in megabytes: ten thousand of those can be tens of gigabytes. On a per-GB plan the bill scales with the job; on Rotating Unmetered it does not move. Unmetered wins.

Sustained, predictable, high volume. If you move the same large amount every month and the target accepts datacenter addresses, the meter is the whole cost, and removing it is the reason to switch.

Low concurrency and low volume. Two crawlers at a time and a few gigabytes a month is a per-GB shape. An unmetered plan there is capacity you pay for and do not use.

For example, suppose a crawler fetches 500,000 product pages a month at about 300 KB each. That is roughly 150 GB, and on a per-GB plan that volume is the dominant cost. Suppose the same crawler needs about 50 connections in flight to finish in a week. Check that count against the Rotating Unmetered sizes on the pricing page, where the byte count stops being a cost at all. Put your own numbers into the proxy calculator, which asks for volume and response size rather than for a guess at how many proxies you want. The same comparison one level up, per gigabyte against per address, is in choosing a proxy pricing model.

If the target refuses datacenter ranges, neither rotating plan applies, because the cheap option does not work at all. Residential is priced per gigabyte because the addresses come from a partner network rather than blocks we own. Check before optimizing the bill: block replay fetches the URL you care about from both kinds of address and reports whether they are treated differently.

What you give up on each

On Rotating Unmetered, concurrency is a ceiling, and on a small plan a low one. A bursty workload (idle for hours, then two thousand requests in flight for ten minutes) is sized by the burst, not the average, and that can cost more than metering the same work would. A per-GB plan absorbs a spike by billing for it; a per-connection plan absorbs it by refusing connections. There is also no volume discount, because there is no volume to discount.

On Rotating Datacenter, the bill scales with bytes, top-ups are needed when the allowance runs out, and unused allowance expires at the end of the billing period.

Rotation behavior is identical either way, as described in the IP rotation guide. Choosing a plan changes what you are billed for, not how rotation works.

Why rotating plans are usually metered

A rotating gateway gives you an endpoint rather than an address, with a pool behind it that many customers draw from at once. The natural unit to charge for is traffic. Node4 can charge for concurrency on Rotating Unmetered because the exits are datacenter addresses on blocks we own, so the bytes crossing them are not bought by the gigabyte. That is not true of residential, where every gigabyte is purchased from a partner network, which is why residential is metered.

What the free tier includes

The free tier is 3 free shared proxies with 1 GB/month bandwidth and 10 concurrent threads. Those are shared datacenter proxies, not a rotating product: the free tier cannot reach the rotating gateway, so it will not let you evaluate rotation behavior, country targeting or sticky sessions. It is useful for everything upstream of that decision: confirming your client authenticates, that your code works through a proxy at all, and that the target responds to a datacenter address.

Deciding, in order

1. Check whether the target accepts datacenter addresses. Test it rather than assuming.
2. If it does, measure two numbers: bytes per request, and how many requests you need in flight at once. Small responses at low concurrency point at Rotating Datacenter; large responses or sustained volume point at Rotating Unmetered.
3. If it does not, the answer is residential, metered per gigabyte whether you rotate on every request or hold a session, and the question becomes how much address diversity the target forces you to buy. Choosing the right proxy type walks that decision from the product end.

Rotating proxies covers the rotation mechanics both plans share. If you are comparing against a per-request scraping API rather than another proxy plan, working out cost per request under each model sets the two side by side, and proxies for high concurrent connections covers sizing the connection count itself.