Proxy Pricing Models: Per IP, Per GB, or Per Connection

The four ways proxies are billed, what each unit quietly punishes, which workload suits which, and the questions to ask before comparing quotes.

Proxy pricing looks like a rate card and is actually a choice of unit. A provider bills you for one of four things: an address for a month, a gigabyte moved, a connection held open, or a request completed. Each unit is cheap for one traffic shape and expensive for another, and a disappointing proxy bill usually traces back to a unit that did not match the traffic. The rate matters much less than that.

This is the reference for the four models: what each one meters, what it silently punishes, which workloads it fits, and what to ask a vendor before you compare two quotes that are not in the same unit. Current rates for everything we sell are on the pricing page rather than typed here, because a figure in an article goes stale the day a ladder moves.

The four billing units

Per IP, per month. You rent an address. Traffic through it is either not counted or counted against a pooled allowance. Dedicated datacenter proxies here are billed this way with no bandwidth meter; shared datacenter proxies are billed per proxy too, with an allowance pooled across the order.

Per gigabyte. You buy bytes, and the pool, the rotation and the address count are the provider's problem. Residential and Rotating Datacenter are the metered products here.

Per concurrent connection. You buy the right to hold a number of connections open at once, and bytes are not counted. Rotating Unmetered is priced this way.

Per request. You pay for each completed call. This is how scraping APIs bill, and we do not sell one; the arithmetic for cost per request covers when that model beats the other three and when to buy it elsewhere.

The rest of this article is about the three we sell, because those are the three a proxy buyer is actually choosing between.

Per IP: what it meters and what it punishes

The meter is time. An address costs the same in a month where it carried ten requests and a month where it carried ten million. That is the appeal and the trap in one sentence.

It fits work built around a stable identity: logged-in sessions that a target should see from one address, partner APIs that whitelist you, monitoring that must come from a known source, and anything where the address itself is part of the integration. It also fits sustained volume, because the marginal request costs nothing and the per-request cost keeps falling for as long as you can keep the address busy.

It punishes three things:

• Idle capacity. An address you provisioned for a peak and used for an hour a week costs the same as one running flat out. Fixed billing bills for the ceiling, not the average.
• Breadth. If a target rate-limits per address, more throughput means more addresses, and a per-IP plan sized for throughput can grow faster than the work it carries. How many proxies a workload needs is the sizing question, and the proxy calculator does the multiplication from request volume, failure share and payload.
• Classification. Datacenter addresses are cheap because they are issued to hosting facilities, and serious targets classify hosting ranges as a class. No amount of per-IP capacity fixes a target that refuses the category.

One thing per-IP billing does not punish that per-GB does: heavy responses. A full page with its images and script bundles costs exactly what a JSON endpoint costs, which at the margin is nothing.

Per GB: what it meters and what it punishes

The meter is bytes. You pay for what moves through the proxy in the period, the address pool is shared and rotated behind the endpoint, and there is no address to size.

It fits variable and bursty work: a crawl that runs one week and rests the next, a job whose scale you cannot predict, and any target that needs residential exits, because residential supply is usually priced by the byte. It also fits light responses. A price field or a small JSON document costs a fraction of what a rendered page costs, on the same plan.

It punishes:

• Payload. Response size is the entire bill. Pulling full HTML when an API endpoint would do, or downloading images your parser discards, multiplies cost with nothing to show for it. Measure your average transfer per request on a sample of real fetches before estimating anything.
• Retries that transfer bytes. A refused connection moves nothing and bills nothing. A block page that returns a full HTML body bills as a page. The distinction is which failures cost you money, and it is worth checking how your targets fail before choosing this unit.
• Running out mid-period. Here the allowance is a gate rather than a meter that keeps running: when it is exhausted the proxy stops answering until you top up or the period renews. A top-up is priced above the plan's own per-gigabyte rate, so a plan sized too small pays a premium for the difference. Bandwidth top-ups explains how they work, and how automatic top-ups avoid the outage without removing the premium.

Two mechanics soften the model here. Same-type plans stack, so two subscriptions of one proxy type sum their allowances rather than competing for one. And consumption against allowance is on the Dashboard while per-proxy history is on Analytics, so a cost spike is visible mid-month instead of on the invoice; what the usage numbers do and do not measure is worth reading before you trust any of them.

Per concurrent connection: the model that inverts the other two

The meter is parallelism. Rotating Unmetered counts how many connections you hold open at once and does not count bytes. Buy a tier, hold up to that many connections, move as much as those connections can carry within the network's safety limits. An HTTPS tunnel or SOCKS5 connection occupies one connection for its whole life, idle or not; a plain-HTTP request occupies one only while it runs.

It fits data-heavy work with a predictable shape: large responses, sustained runs, a scraper whose concurrency you control. It punishes spiky concurrency, because the tier is sized for the burst rather than the average, and it punishes the same thing per-IP billing punishes, which is paying for a ceiling you rarely reach. The unmetered tier against per-gigabyte billing works through what the inversion does to a data-heavy job, and how concurrency is actually sold covers what enforces the number and what changes it mid-month.

A caution that applies to every provider selling this unit: the connection cap is the product. Copy that describes a connection-priced plan as having no limits is describing the invoice wrongly.

Matching the unit to the traffic

Profile the traffic before reading a single rate card. Four numbers decide the unit:

1. Requests per period. Sustained and high favors a fixed unit, per IP or per connection. Low or irregular favors per GB.
2. Average transfer per request. Heavy favors a fixed unit. Light favors per GB.
3. Identity requirements. Sessions that must persist on one address favor per IP. Work that benefits from a fresh exit per connection or request favors a rotating tier, in whichever unit the volume suggests.
4. Target classification. A target that refuses hosting ranges needs residential, which is per GB, and the other three numbers then decide the plan size rather than the unit.

Some worked shapes:

• Account management, twenty logged-in identities, modest traffic. Per IP. Identity is the requirement; bytes are irrelevant.
• Daily price check across a catalog, small JSON responses, one target. Per GB on a rotating tier, or per IP if the target tolerates one address. The payload is light enough that bytes are cheap, and breadth is what the target's rate limit demands.
• Weekly full crawl of rendered pages, tens of gigabytes, controlled concurrency. Per connection. The byte meter is the thing to remove.
• Defended consumer site that classifies datacenter ranges. Residential per GB, sized from the payload measurement, with everything that can be fetched from an API kept off the residential path.

Choosing the right proxy type for a target covers the half of this that is about the target rather than the bill.

Reading a vendor quote

Two quotes in different units cannot be compared as printed. Convert both to cost per delivered page for your own traffic profile, which is the only number that normalizes them, and the per-request arithmetic is written for that conversion. While converting, ask every vendor the same questions:

• What does a gigabyte measure? Bytes in both directions, or response bodies only? Compressed or raw? The answer can move a per-GB estimate by a large fraction.
• What happens to a failed request? Does a blocked page count against the allowance? Does a timeout? Under per-IP billing the answer is nothing; under per-GB it depends on what the failure transferred; under per-request it depends on the provider's policy.
• What happens when the allowance runs out? Silent overage at a higher rate, a hard stop, or a top-up you have to buy. Each is defensible; not knowing which is not.
• Is the concurrency figure a limit or guidance? Per-plan thread numbers here are fair-use guidance rather than enforced ceilings, except on the connection-priced tier where the number is the product. A vendor that cannot say which is which will surprise you under load.
• Can you export raw usage? A bill you cannot reconcile against your own request logs is a bill you cannot dispute.

Then pilot. A week or two at production concurrency, tracking cost per delivered page and the share of requests that needed a retry, tells you more than any calculator. Size the pilot to the traffic you have, not the traffic you fear.

Where we lose on price

Per-request pricing is cheaper for low, spiky volume against ordinary pages, and we do not sell it. Residential is priced by the byte because that is how residential supply is usually priced, and it is not competing on cost with datacenter; it is buying acceptance by targets that refuse hosting ranges. And a fixed unit that is cheap at sustained volume is expensive for a job that runs one hour a week, which is exactly the job a per-GB plan should carry.

If you are comparing us with a provider you already pay, the IPRoyal comparison and the Proxy-Cheap comparison put the units side by side rather than the headline rates. When the unit is settled, changing or upgrading a plan covers how moving between sizes is handled, and your invoice, line by line shows what each unit looks like once it is billed. Payment method is a separate axis from pricing model, and if a card is awkward for you, buying with Bitcoin covers the checkout.