How to Plan Mobile Proxy Bandwidth (Capacity Math)

Your mobile proxy plan ran out of bandwidth on day fourteen. Overage rates run 1.5 to 5 times list price, and by the time the alert fires you’ve already blown the math by 10x. Here’s the formula that actually predicts your monthly bill, so this doesn’t happen again.

Bandwidth on mobile proxies is expensive, so getting the plan right is worth real money. This article covers the formula, page weight tables for major targets, retry overhead math, and worked examples for five common workloads.

The bandwidth equation

The fundamental formula is this: monthly gigabytes equals requests per second, times average response bytes, times one plus retry overhead, times 86,400 seconds per day, times 30 days, divided by 1024 cubed bytes per gigabyte.

Each input has a typical range and a worst case, and the final number can swing 5x to 10x based on input choices that look minor. Miss your page weight estimate by 2x and you’ll miss your overage charge by 2x too.

Requests per second

For continuous workloads, use your peak rate. For burst workloads, compute the average over the active window, not the whole day.

Typical ranges by workload: an ecom price tracker on a single retailer runs 0.5 to 5 requests per second. Across fifty retailers, that’s 5 to 50. A Google SERP tracker is small, 0.1 to 2. Social listening mass scrape can hit 5 to 100. An ad verifier is tiny, 0.05 to 1. An account warmer is the smallest, 0.01 to 0.5. A sneaker bot at drop time is the extreme, 50 to 500 requests per second in a burst.

A team that says “we scrape Shopee” without specifying a rate often starts planning around 1 request per second and discovers the real workload runs at 20. That gap alone busts a bandwidth plan in the first couple of weeks.

Average response bytes

Page weight is the input most teams underestimate, because modern web pages are heavier than people expect.

Some reference points: a simple JSON API response is around 5 KB. Tiny static HTML is 30 KB. A Google SERP result page is 200 KB. A Shopee product page is 800 KB. A Meta ad page is 1.5 MB. An Amazon product page is 1.2 MB. A TikTok video page, uncompressed, is 3.5 MB. A YouTube video page without the video itself is 2.5 MB.

Don’t guess. Fetch twenty pages from your real target, average the response bodies, add HTTP overhead, and assume some retries on top. Use the mean for plan capacity, the 95th percentile for headroom, and the max as a sanity check.

Retry overhead

Retries are pure cost. Every blocked or failed request consumes bandwidth without producing usable data, and how much overhead you carry depends on your target’s block rate.

Friendly targets, under 5% block rate, add 5% to 10% overhead. Moderate targets, 5% to 15% block rate, add 15% to 30%. Hostile targets, 15% to 30% block rate, add 30% to 50%. Very hostile targets, above 30%, add 50% or more, and at that point it’s worth reconsidering the approach entirely.

Multiply your base bandwidth by one plus the retry overhead percentage before you do anything else with the number.

Headroom

Even after accounting for retries, build in headroom for traffic spikes, target site changes, and scrape expansion. Standard headroom is 30% on top of your computed need, and it should be higher if your workload is variable rather than steady.

Worked example: Shopee price tracker

Tracking 100,000 SKUs across Shopee Singapore, refreshed once per day, continuous load. That’s 100,000 requests per day spread over 24 hours, at 800,000 bytes per request, with 25% retry overhead.

Daily bytes: 100,000 × 800,000 × 1.25 = 100 GB. Monthly: 3,000 GB. With 30% headroom: 3,900 GB a month.

This workload needs a 4 TB per month plan. Bandwidth, not request volume, is what dominates the bill at this scale.

Worked example: Google SERP tracker

Five thousand keywords tracked daily, at 200 KB average response size, with 30% retry overhead because Google blocks aggressively.

Daily: 1.3 GB. Monthly: 39 GB. With headroom: 50 GB.

That’s modest. Google’s small response sizes keep bandwidth low even though the success rate on this target is challenging.

Worked example: TikTok content scraping

Twenty thousand video pages scraped daily for sentiment analysis, at 3.5 MB per page (no video stream), with 35% retry overhead.

Daily: 94.5 GB. Monthly: 2,835 GB. With headroom: 3,700 GB.

TikTok pages are heavy, and scraping at meaningful scale on TikTok is a bandwidth-intensive workload by itself, independent of how well-behaved the target is.

Worked example: small dev exploration

A developer testing scrapers against one thousand small JSON APIs daily, at 5 KB responses, with 10% retry overhead.

Daily: 5.5 MB. Monthly: 165 MB. That’s effectively free, and it fits inside any plan’s free tier.

Bandwidth-saving techniques

Once you know your bandwidth profile, a handful of techniques reduce actual consumption.

Turn on accept-encoding for gzip and brotli. Most modern targets serve compressed responses, and compression cuts bandwidth 50% to 80% on text, HTML, and JSON.

Use selective downloads. If you only need metadata, a HEAD request confirms presence without pulling the body. Range requests fetch only specific bytes when you don’t need the whole page.

Respect cache headers. If the target serves cache-control or etag headers, honor them. Re-fetching a page that hasn’t changed is pure waste.

Terminate early. Stream responses and abort once you have what you need. If the data you’re after sits in the first 50 KB of a 500 KB page, don’t download the rest.

Suppress unneeded assets in headless browsers. Block images, fonts, and CSS. Most pages still function for scraping purposes without them.

Spotting bandwidth anomalies

Bandwidth anomalies are usually a signal of a real underlying problem. Three patterns worth alerting on.

A sudden 3x increase usually means a scraper hit an infinite loop or ran into a new, heavier page template. A gradual 30% rise over several weeks usually means the target’s page weight grew, or the retry rate crept up. An unexpected drop to zero usually means a scraper is broken or misconfigured.

A reasonable alert threshold is daily bandwidth deviating more than 50% from a seven-day rolling average.

The concurrency tradeoff

Concurrency and bandwidth interact directly. More concurrency against the same target means more bandwidth consumed in the same time window, but it also means more rate-limit triggers and more retries.

At one concurrent request, success rate might run around 95%. At five concurrent, 92%. At ten, 88%. At twenty, it drops to 78%. At forty, it drops to 60%.

Past the target’s tolerance point, doubling concurrency doesn’t double useful throughput. It doubles bandwidth consumption for marginal gains in actual data collected. Find that cliff during your proof-of-concept phase and stay safely below it.

A production checklist

Run this template per workload: requests per day, average bytes, retry overhead, headroom, computed daily and monthly totals, plan choice with its overage rate, and any relevant notes.

Tag every request with a workload ID. End-of-month reports built on that tagging will tell you whether your allocation is correct, or whether one workload is quietly starving the others.

Singapore Mobile Proxy runs on real SingTel, M1, and StarHub SIMs, with transparent per-gigabyte pricing and per-port bandwidth metrics so you can match the numbers above against a real plan. Run the formula in this article against your own workload, add 30% headroom, and pick accordingly. Visit Singapore Mobile Proxy to see current plans.

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