Estimate Proxy Bandwidth From Valid Outcomes, Not Page Size

When a proxy plan is priced by gigabytes, it is tempting to multiply “average page size” by request count. That estimate usually misses redirects, failed bodies, retries, uploads, headers, browser assets, cache behavior, and the gap between an HTTP 200 and a result your application can actually use.

Here is a small capacity model that is much harder to fool.

Start with the denominator that matters

Define a valid outcome first: the required fields are present, the market and locale are correct, freshness passes, and the response is not a block page or consent screen.

Then calculate each workload cell separately:

monthly_bytes = valid_outcomes
              × attempts_per_valid_outcome
              × billable_bytes_per_attempt

capacity_bytes = monthly_bytes
               × (1 + growth_rate)
               × (1 + safety_headroom)

Measure attempts_per_valid_outcome during a pilot:

attempts_per_valid_outcome = all_billable_attempts / valid_outcomes

That ratio reveals retry amplification without pretending every failed request is independently recoverable.

Keep three byte counters

Use matching request IDs and time windows to compare:

1. Application payload bytes — what the app consumed after decoding.
2. Client transfer bytes — what curl, the HTTP library, or the browser reports.
3. Provider-billed bytes — what the proxy dashboard counts.

They are not interchangeable. The application may omit headers and failed attempts. Automatic decompression can make the in-memory response larger than the transferred body. A provider may count uploads, redirects, error bodies, or both directions of a tunnel.

The contract's billing definition should drive the forecast; the other counters help explain mismatches.

Never mix browser and API averages

An API request might transfer a small JSON response. A browser visit can load HTML, scripts, styles, fonts, images, video, analytics, API calls, service-worker updates, and speculative resources.

Measure cold-cache and warm-cache browser sessions separately. Isolated profiles and rotating workers may not keep the cache savings you see on a developer laptop.

Block only resources proven unnecessary for the authorized output. Breaking consent, security, or application behavior to save bandwidth produces an invalid benchmark.

Use a range, not one number

For each target × region × client × proxy product × session mode cell, create low, expected, and high assumptions for:

• attempts per valid outcome;
• billable bytes per attempt;
• monthly valid outcomes.

Example:

Scenario	Outcomes	Attempts/outcome	MB/attempt	Base GB
Low	200,000	1.05	0.20	42
Expected	200,000	1.18	0.24	56.64
High	200,000	1.45	0.32	92.8

With 15% growth and 20% safety headroom, the expected capacity is about 78.16 GB.

Those are example numbers, not defaults. A browser workflow can be orders of magnitude larger.

Calibrate before committing

Run a small authorized pilot:

• representative targets for every critical cell;
• concurrency one at first;
• retries disabled for the baseline;
• planned bounded retries for the second run;
• cold and warm cache separated;
• application, client, and provider counters reconciled;
• 403 and 429 treated as stop signals, not rotation triggers.

Extend the pilot when a critical cell still has an unstable range. A global average can hide the one small market that drives the purchase.

Finally, review overage pricing, rollover, expiration, minimum commitment, and whether the vendor calls a billion bytes a GB or uses GiB.

I work with 98IP, a proxy service. I am sharing this because forecasting from successful outcomes makes plan comparisons more honest and reduces retry waste. Product information: https://en.98ip.com/?k=dev

Use proxies only for authorized systems and data. Follow destination terms, robots guidance, rate limits, privacy obligations, and data-minimization requirements. Do not budget traffic for repeatedly evading denials.