Residential Proxy Pricing: What You Actually Pay Per GB

As of September 2026, published entry pay-as-you-go rates for rotating residential proxies sit roughly between $3 and $9 per GB across the major vendors, with committed and enterprise tiers published as low as the $1 to $4 range at large volume. That spread of 3x to 6x between the entry rate and the committed rate is the single biggest lever on your bill, bigger than any difference between providers at the same tier.

Three things follow from that, and they decide most purchases:

• If your target site accepts datacenter IP ranges, per-GB residential billing is the wrong product. A flat-rate datacenter plan costs a fraction of a cent per page at volume.
• If you genuinely need residential exit IPs, the tier you commit to matters more than the logo on the invoice.
• If your pages are heavy or need JavaScript rendering, per-request billing usually beats per-GB billing, because you stop paying for megabytes of images, fonts and analytics scripts you never parse.

The rest of this guide is the math behind those three sentences.

Vendors use six billing shapes. Knowing which one you are buying tells you where the cost leak will be.

The models are not interchangeable. Per-GB billing punishes heavy pages. Per-request billing punishes very light pages. Flat-rate billing punishes low volume. Match the model to the shape of your traffic before you compare rates, because comparing a $5 per GB residential quote to a $75 flat plan without normalising both to cost per successful record tells you nothing.

For a deeper breakdown of the flat-rate and thread-based side of that table, see our guide to datacenter proxy pricing models.

The table below reflects each vendor's own published pricing pages as of September 2026. Proxy pricing changes frequently, promotional rates come and go, and enterprise quotes are negotiated privately and are not public. Treat this as the shape of the market, not as a quote, and check each vendor's current pricing page before you budget.

Two structural notes matter more than the exact digits. First, several vendors publish a lower headline rate that applies only to a specific pool tier, and route premium or city-level targeting to a higher rate. Second, the advertised committed rate usually assumes you consume the whole block. If you do not, see the next section.

Your effective rate is the list rate multiplied by three factors that no pricing page shows.

effective $/GB = list rate
               x (1 / success share)          # you pay for failed attempts too
               x (purchased GB / consumed GB) # you pay for GB you never used
               + overage exposure             # the rate above your commit

Work an example. You buy a 100 GB monthly block at $6 per GB, your pipeline succeeds on 80% of attempts, and you consume 80 GB before the month resets.

6.00 x (1 / 0.80) x (100 / 80) = $9.38 per consumed, successful GB

That is a 56% premium over the sticker price, and nothing went wrong. The pipeline behaved normally.

Multiplier one: failure share

Every blocked response, CAPTCHA interstitial and timeout still moved bytes through the proxy, and metered vendors bill those bytes. A block page is small in raw HTML terms, often 5 KB to 30 KB, so the direct byte cost of a failure is minor. The real cost is the successful retry, which pays full page weight a second time. Raw HTML pipelines absorb this. Headless pipelines do not, because a failed render still pulled the entire asset bundle before the block was detected. Retry policy is a pricing decision, not just a reliability decision. Our guide on detecting when your scraper is blocked covers classifying those responses so you stop retrying the ones that will never succeed.

Multiplier two: unused prepaid GB

Bandwidth blocks that reset monthly convert a per-GB price into a subscription. If you routinely finish the month at 70% consumption, you are paying 1.43x list. Ask two questions before you commit: does unused bandwidth roll over, and for how long. A non-expiring package at a slightly higher list rate is often cheaper in practice than an expiring package at a lower one.

Multiplier three: overage

Overage is priced above your in-plan rate at most vendors, sometimes well above it. Traffic is bursty, so a pipeline sized exactly to its average will overrun in any month with a target redesign or an extra crawl. Size the commit to your median month and confirm the overage rate in writing, or size it to your peak and confirm rollover.

If bandwidth accounting itself is unfamiliar, our explainer on bandwidth in proxy services defines what actually gets metered, including request headers, TLS handshakes and CONNECT tunnels.

Cost per GB is a vendor metric. Cost per 1,000 successful records is a business metric, and it is the only number that survives a change of provider, pool or fetch strategy.

Converting between the two takes one input: bytes per successful page. The table below uses 1 GB = 1,000 MB, which is how most proxy dashboards count, and prices 100,000 pages at both the $6 list rate and the $9.38 effective rate calculated above.

The span from the top row to the bottom row is 23x on identical data. Before you negotiate a rate, check whether the page you are rendering actually needs rendering. Many product and listing pages ship their data in embedded JSON or in a public XHR endpoint that a plain fetch can reach, and that single change moves you three rows up the table.

Per GB against a flat rate

A flat-rate plan has no byte meter, so its cost per page falls as volume rises. SparkProxy's published plans are flat-rate datacenter plans with unlimited bandwidth and 30 days validity: Starter at $75 per month with 100 threads and 5 whitelist slots, Core at $140 with 250 threads and 10 slots, Boost at $240 with 500 threads and 15 slots, and Plus at $440 with 1,000 threads and 25 slots.

At a $6 per GB residential list rate, the $75 Starter plan is break-even at 12.5 GB per month, which is roughly 104,000 pages of 120 KB raw HTML.

The honest caveat: this comparison is only valid where datacenter IPs actually work on your target. Residential exits exist because some sites score datacenter ASNs harshly, and no amount of flat-rate pricing fixes a 100% block rate. Test first, then price. Our comparison of residential and datacenter proxies covers where each type holds up.

The second caveat is that "unlimited" is bounded by the plan's speed ceiling, not by a byte quota. SparkProxy's Fair Usage speed caps run 25 Mbps on Starter, 50 on Core, 100 on Boost, 150 on Plus, 200 on Pro, 250 on Pro+, and up to 1 Gbps on custom arrangements. That is a ceiling rather than a guaranteed rate, and Pro and Pro+ are not publicly priced. A 25 Mbps ceiling is about 11 GB per hour if you saturated it continuously, so the practical limit on the entry plan is throughput and thread count, not bandwidth. Size on threads and concurrency, not on gigabytes.

Per GB against per request

Credit-based billing prices a request by what it costs to serve, not by what it weighs. On the SparkProxy Scraping API, a plain fetch is 1 credit, a JavaScript render is 5, and a screenshot or PDF is 10. Plans are Starter at $49 for 250,000 credits and 50 concurrent requests, Growth at $99 for 1,000,000 credits and 100 concurrent, Pro at $249 for 3,000,000 credits and 200 concurrent, and Scale at $599 for 8,000,000 credits and 400 concurrent. There are 1,000 free credits with no card, which is enough to run the price test in the next section.

Now find the page weight at which one credit costs the same as the bytes it would have consumed on a per-GB plan, using the Growth rate.

Almost no real page is under 55 KB rendered. That is the point most buyers miss: on a per-page basis, per-request billing is cheaper than per-GB residential for essentially every page heavy enough to need a browser. Per-GB billing only wins when you are fetching small, light responses such as JSON APIs, and when you need a residential exit IP that a managed API cannot give you. The trade-off analysis in web scraping API vs self-managed proxies goes further into where each one breaks.

Ask these before you pay. Every one of them has moved a real invoice by double digit percentages.

1. Does unused bandwidth expire, and does it roll over? Get the rollover window in months, not in adjectives.
2. What is the overage rate, exactly? Compare it to your in-plan rate as a multiple.
3. Is premium or city-level targeting billed at a different rate? Country targeting is usually included. Deeper targeting often is not.
4. What counts as billable traffic? Confirm whether blocked responses, redirects, CONNECT tunnels and request headers are metered.
5. What are the concurrency and speed limits? On a flat-rate plan these are the real product. On SparkProxy that is the thread ladder of 100, 250, 500 and 1,000 across Starter through Plus.
6. How many sub-users and whitelist slots? SparkProxy publishes 5, 10, 15 and 25 whitelist slots across those same four plans. If you run multiple teams or servers, a low slot count forces credential sharing.
7. What is the refund window and is there a trial? A provider unwilling to give you a small paid test on your own targets is telling you something.
8. Is the price locked for the term? Promotional first-month rates that renew at list are common.

If you are building a formal evaluation, the criteria list in what to evaluate when selecting a proxy service pairs with this checklist.

Vendor benchmarks are run on vendor-chosen targets. Run yours on your own URLs.

1. Take 500 real URLs from your production target list, not a homepage and not a test endpoint.
2. Run the same 500 through each candidate, at the same hour, with the same retry policy.
3. Record two numbers per candidate: billed bytes from the vendor dashboard, and successful parses from your own logs. Do not trust HTTP 200 alone, because soft blocks return 200 with a challenge body.
4. Divide, and compare only cost per 1,000 successful records.
5. Repeat once during your target's peak traffic hours. Block rates and page weights both move.

Measuring per-response size through the SparkProxy gateway takes one curl flag. The gateway is gateway.sparkproxy.io on port 11000 for HTTP and HTTPS, port 11002 for sticky sessions, and port 13000 for SOCKS5.

curl -x http://USERNAME:PASSWORD@gateway.sparkproxy.io:11000 \
     -s -o /dev/null \
     -w "%{http_code} %{size_download} %{time_total}\n" \
     https://example.com/product/12345

Then turn the log into the number you actually buy on:

def cost_per_1k_records(billed_gb, price_per_gb, successful_records):
    """Effective spend per 1,000 successfully parsed records."""
    if successful_records == 0:
        raise ValueError("no successful records: the run tells you nothing about price")
    return (billed_gb * price_per_gb) / successful_records * 1000

# 500-URL trial: 0.42 GB billed at $6.00/GB, 388 records parsed cleanly
print(round(cost_per_1k_records(0.42, 6.00, 388), 2))  # -> 6.5

Those input numbers are placeholders for your own run, not measurements published by SparkProxy. Swap in what your dashboard and logs report.

If your successful-record count depends on holding a session across several requests, price the sticky path separately, since session length changes both byte volume and success rate. See rotating vs static residential proxies for how that choice affects consumption.

That last row is where most mature pipelines land. Route every request to the cheapest path that works for that domain, escalate only on a classified block, and record which domains needed escalation. The escalation rate becomes your budget model, and it is usually far lower than a blanket "we need residential" assumption suggests.