Residential proxy pricing models compared

Why residential proxy pricing is hard to compare

Pull up five residential proxy providers and you’ll get five different pricing structures that don’t map onto each other cleanly. One charges per gigabyte. Another charges per IP. A third bundles everything into a flat monthly fee with a soft usage cap. None of these numbers tell you what you actually want to know, which is: what does it cost to run my scraper or my automation job to completion.

We run proxy infrastructure ourselves, across residential, mobile, and datacenter pools, and we’ve built pipelines that burn through bandwidth on other people’s networks as a line item. The pricing model a provider picks isn’t cosmetic. It changes how much a scraping job costs you depending on what you’re actually doing: high page-weight sites versus lightweight API calls, long sessions versus one-shot requests, broad geographic coverage versus a single country. Here’s how the four common models actually work, and where each one quietly costs you more than the headline number suggests.

Pay-per-GB: the default for a reason

Bandwidth-metered pricing is the most common model in residential proxying, and it’s the most common for a structural reason: the provider itself is usually paying for that traffic, either through an SDK partnership with app developers who bundle a proxy client into free apps, or through a peer network where residential devices relay traffic in exchange for something. Either way, the provider’s own cost scales with bytes moved, so their pricing does too.

This model rewards lightweight traffic. Scraping a JSON API endpoint that returns 20KB per call is cheap under pay-per-GB. Scraping a modern e-commerce page with lazy-loaded images, video previews, and three ad networks firing in the background is not, because a full-page load can run into multiple megabytes once you count every asset the browser fetches. If your scraper renders pages in a headless browser instead of hitting an API directly, your GB consumption per successful data point can be five to ten times higher than a request-only approach, and that difference lands directly on your bill.

The practical move here is blocking unnecessary resource types (images, fonts, video, most third-party scripts) at the browser level before they hit the proxy, since every blocked request is a request you never pay bandwidth for. This is a request-shaping decision on your side, not a proxy configuration trick, and it’s the single biggest lever on pay-per-GB cost.

Flat-rate / unlimited: the cap is never really unlimited

Unlimited residential plans exist because it’s a strong marketing word, not because the underlying network has infinite capacity. Somewhere in the terms of service or a support conversation there’s a fair-use ceiling, a thread/concurrency limit, or a throttle that kicks in once you’re moving enough traffic to matter. The provider is still paying per byte on their end; they’re just absorbing that variance across a large customer base and hoping your usage sits near the average.

The way to evaluate a flat-rate plan is to ask directly what the concurrency and thread caps are, since that’s the real constraint, not the word “unlimited” on the pricing page. A plan capped at 50 concurrent connections behaves completely differently from one capped at 500 once you’re running a distributed scrape across thousands of targets, even if both are billed the same flat monthly rate. If a provider won’t state a concurrency number in writing, treat that as a gap in the pricing model, not a feature.

Flat-rate plans make the most sense when your traffic volume is predictable and moderate. They make less sense for spiky workloads, like a monthly full-catalog re-scrape that needs to move a huge volume of data in a short window, because that’s exactly the pattern fair-use throttling is designed to catch.

Per-IP pricing: paying for the pool, not the traffic

Some providers, especially on the datacenter and static-residential (ISP) side, charge per IP address rather than per byte. You pay a flat fee per IP per month and then move as much traffic through it as the connection allows. This model shifts the cost driver from bandwidth to pool size and IP diversity.

Per-IP pricing makes sense when your bottleneck is distinct identities rather than raw throughput, for instance when you need many different source IPs to distribute request volume across a target site’s per-IP rate limits, rather than needing a lot of total bandwidth through any single one. It tends to cost more per byte moved than pay-per-GB residential if you’re pushing heavy traffic through a small number of IPs, but it’s more predictable, since your bill doesn’t move with a bad day of page bloat.

The trap with per-IP pricing is buying more IPs than your target actually requires. Rate limiting on the target side is usually based on request frequency and behavioral signals, not purely on IP count, so doubling your IP pool without changing request pacing or session handling often just doubles your bill without improving success rate.

Tiered subscriptions: bundled convenience, opaque unit economics

The fourth common model bundles a GB allowance, a session or IP limit, and sometimes geo-targeting options into named tiers, similar to how a SaaS product prices seats. This is the easiest model to buy from and the hardest to evaluate, because the effective price per GB usually drops as you move up tiers, which pushes buyers toward committing to more volume than they need in order to hit a better unit rate.

The way to compare tiers honestly is to divide the tier price by its stated GB allowance and treat overage pricing as the real marginal cost, since that’s what you pay once you’re not perfectly sized to a tier. Overage rates on subscription plans are frequently worse per-GB than the base tier rate, sometimes worse than a plain pay-per-GB competitor’s list price, because overage is priced as a convenience charge rather than a competitive rate.

What none of these models price in

Pricing pages describe cost per byte or per IP. They don’t describe cost per successful request, which is the number that actually matters for a production scraping pipeline. A cheap plan that gets blocked, fingerprinted, or rate-limited on your target site and forces retries burns bandwidth on failed attempts you still pay for. A more expensive plan with better session handling, cleaner IP reputation, and lower detection rates on the sites you actually care about can end up cheaper per successful data point, even at a higher headline price.

This is where bot-detection systems on the target side become part of the cost equation, even though no proxy pricing page mentions it. Sites running fingerprinting and behavioral analysis (checking TLS handshake characteristics, header ordering, mouse movement patterns, and IP reputation history) will flag and block traffic regardless of which pricing tier moved it. We don’t publish techniques for defeating those systems here, because that’s not a responsible use of this space and it wouldn’t hold up as reliable advice anyway, defenses change constantly. What’s worth understanding is that IP reputation and network diversity, the things residential and mobile proxy pools actually sell, are part of why they exist as a category at all: legitimate residential IP space carries less baseline suspicion than datacenter ranges on sites that check for it, which is a structural fact about how these networks are built, not a guarantee about any specific outcome.

No provider or technique here is being called undetectable or risk-free, and none should be. Pricing model aside, every proxy network has a failure rate against production bot-detection systems, and that failure rate should factor into your real cost calculation just as much as the dollar figure per GB.

Choosing a model for your actual workload

Match the model to your traffic shape, not to whichever plan looks cheapest on the pricing page. Lightweight, API-style scraping favors pay-per-GB. Predictable, moderate-volume automation favors flat-rate with a known concurrency cap. Distributing requests across many identities to respect per-IP rate limits favors per-IP pricing. High-volume operations that can commit to a stable baseline favor tiered subscriptions, as long as you price the overage rate honestly.

Whatever model you land on, calculate cost per successful request before committing, not cost per GB or per IP in isolation. That’s the number that tells you what the pipeline actually costs to run.

For more breakdowns like this on scraping infrastructure, proxy pools, and the detection systems they run up against, head back to Data Research Tools.

Get new guides and videos first — join the Telegram channel.