Per-GB Proxy Pricing

What you pay for

A gigabyte is a unit of consumption within a proxy product. The product supplies a route to the internet through its exit IPs; the tariff determines how the use of that route is charged. You may buy a traffic balance in advance, receive a recurring allowance, or pay for measured usage under an account agreement. These arrangements can all have a price per GB, although their payment dates and commitments differ.

Access often works through a gateway: your application connects to an address supplied by the provider, and the service selects an exit from an available pool. Changing the exit can leave the same account allowance in use. A large advertised pool therefore describes possible access, not a list of addresses reserved for you. Some products instead combine a traffic charge with access to particular IPs.

The billing unit does not determine the network type or session behavior. Datacenter, ISP, residential, and mobile products can be sold by traffic. Rotation, the ability to keep an IP for a session, and exclusive use of an address are separate product properties. Paying for more GB does not extend a session that has its own time limit or restore an unavailable exit.

Choose the required access before comparing rates. For a regional checkout test, the useful product must provide an accepted IP in the required location and keep the session working through checkout. A cheaper allowance that cannot do that does not meet the task. Conversely, buying a more expensive network brings no automatic benefit when the simpler one already works reliably.

The allowance also says nothing about delivery speed. Volume determines how much can pass; throughput determines how quickly it passes; concurrency determines how much work can be active together. A large balance cannot compensate for a route that is too slow to finish a time-sensitive job.

How a completed job becomes paid traffic

Start with the whole transaction. A program may first obtain a list of documents, follow download links, retrieve the files, and then repeat a few downloads. Each stage can use the paid connection, even though the final archive contains only one copy of each document.

Consider an illustrative archive job that successfully stores 300 documents. The following assumed traffic totals describe separate, non-overlapping parts of the run. They are an accounting example, not measurements of a particular site or provider.

With decimal units, that run consumes 0.308 GB. At an assumed $4.50/GB, its traffic charge is $1.386, or about $1.39 before any other charges. The useful distinction is between the 240 MB associated with retained documents and the 308 MB used by the process. Removing the redundant downloads would save 48 MB without reducing the archive; removing the document discovery step could stop the job working.

The provider's measurement boundary matters. Published proxy policies commonly count data sent toward the site as well as data received, including HTTP headers and bodies. Upload-heavy work therefore consumes an allowance even when the site's reply is short. Policies differ over connection traffic, encryption overhead, and service-generated errors. A counter of downloaded file contents is not enough to reconstruct every bill.

An HTTPS tunnel can carry encrypted bytes that the proxy measures without reading the protected content. For budgeting, use the provider's stated method and a measured run; there is no universal overhead percentage to add to every request. Applying such a percentage to a counter that already includes those bytes would count them again.

Why GB and GiB show different numbers

A gigabyte (GB) contains 1,000,000,000 bytes. A gibibyte (GiB) contains 2³⁰ bytes: 1,073,741,824 bytes, or 1,024 MiB. GB uses decimal powers; GiB uses binary powers. They measure the same kind of quantity with different-sized units.

For example, 32 GiB is 34.359738368 GB, approximately 34.36 GB. The number expressed in GB is about 7.37% higher because each GiB contains 1.073741824 GB. No extra traffic has appeared: both readings describe the same byte count. A 32 GB allowance, in turn, is approximately 29.80 GiB, so matching the printed number does not make two allowances equal.

Before reconciling an application's counter with billed usage, convert both values to the same unit. Check the provider's definition rather than relying on an abbreviated label, then check the accounting boundary. Rounding is a separate issue: a shortened dashboard reading does not reveal the precision used for billing.

Why the workflow matters as much as the page

First and repeat visits differ

A first visit may download the resources needed to display and operate a site. A later visit in the same browser can reuse some local resources, while a fresh browser profile may have to obtain them again. This makes the way you start and reuse browser sessions part of the traffic model.

Caching has several outcomes. A fresh local copy can be used without downloading that resource again. A stale copy may require a conditional request; a 304 Not Modified response allows reuse of the stored content, but the validation exchange still uses the network. A changed or non-reusable resource requires a new transfer. Keeping a profile does not guarantee that every resource will be cached.

For a monitoring job, cached assets may be useful. For a test of a new visitor's experience, they may invalidate the test. Measure under the conditions the task actually requires. A cheap repeat visit is not a sound estimate for thousands of independent first visits.

The output format can also mislead. Taking a screenshot locally creates an image from content already loaded; it does not by itself send the screenshot back through the proxy. Uploading that image through the proxy would be another transfer. A remotely hosted browser or screenshot API can have a different charging model, so its output size should not be treated as the traffic of an ordinary local browser.

Downloads and video need different estimates

For a file-transfer job, document sizes, duplicate detection, and the ability to resume interruptions often dominate consumption. For a video test, duration and bitrate become more useful than page count. The initial page can be small while the player continues fetching media for as long as the test runs.

Suppose a test receives an average of 6 megabits per second of media data for 18 minutes. Dividing by eight converts bits to bytes: 6 × 1,080 ÷ 8 = 810 megabytes, or 0.81 GB. Repeating that complete test from 12 locations would transfer 9.72 GB of media alone. This is an assumed workload; the player interface, other requests, and counted overhead come in addition. Adaptive quality and buffering can change the actual transfer.

Lowering playback quality is a saving only when the test still answers its question. A brief check that a video starts can use a short observation window. A test of sustained high-quality playback must receive enough of that stream to evaluate it. The required evidence determines which data can be omitted.

These differences explain where traffic pricing fits. Brief regional checks and intermittent access to a useful pool can need little data. Continuous media tests or repeated large downloads can consume the same allowance rapidly. Both are technically possible with a suitable product; their economics depend on the amount of work, its schedule, and the available alternatives.

Build a forecast from the mix of work

Define completion before measuring. A successful document task might mean a readable file with the expected identifier; a regional test might require a completed interaction and a recorded outcome. A successful connection or an HTTP status by itself does not establish that the work is complete.

Use a pilot with the intended locations, session settings, software, and level of parallel activity. Separate its credentials or usage reporting from unrelated work. Record the usage change over a matching period, allowing for the provider's reporting delay, and count completed tasks as well as attempts. If background activity is part of normal operation, include it or measure it separately instead of silently excluding it.

Weight the different kinds of operation

A useful forecast preserves the expected mix. Suppose a pilot supplies the following assumed averages, already including the normal requests and retries needed for each completed operation. Each planned operation belongs to just one category.

At the same assumed $4.50/GB, the forecast traffic charge is $67.986, approximately $67.99. Media checks account for fewer than one in thirteen operations but almost 60% of the traffic. Optimizing the much more numerous follow-up checks may therefore have less effect than changing the media test appropriately.

The general calculation is the sum of each task count multiplied by its measured average traffic. Add separately measured setup or shared activity only if it is outside those averages. Likewise, retries already present in the pilot must not be added a second time using a failure multiplier.

Test what can change the forecast

An average is useful only while the work remains comparable. A switch to new browser profiles can remove cache savings. A different location can receive a different page or media stream. A longer observation window can collect more background data. Recheck the affected category after such changes instead of applying the old average to the whole project.

Test a less favorable but plausible run as well as the ordinary one: larger documents, fresh sessions, or a period with more interruptions. Keep its assumptions visible. A reserve derived from those conditions is more informative than an unexplained percentage added to every budget.

For choosing between suitable services, translate each test into spending for the same completed workload. Include the traffic actually consumed and any unavoidable purchase commitment. A low price per GB can be useful, but it cannot settle a comparison when one service needs a different number of attempts or cannot finish the required sessions.

Match the purchase to the work calendar

The forecast above estimates consumption. The amount you must pay can differ because the product sells traffic in packages, requires a subscription, or adds a separate access fee. Read the offer as a complete purchase: what becomes available, on which dates, and what payment authorizes further use.

An illustrative scheduling problem shows why dates matter. A project needs 8 GB before a billing renewal and 28 GB afterward. A hypothetical 30 GB monthly allowance costing $90, with no rollover and no other fees, requires two monthly payments: $180. A hypothetical non-expiring balance sold in 20 GB blocks at $80 requires two blocks: $160, leaving 4 GB available. Both arrangements are assumed to supply equivalent access. The $3 monthly headline rate is lower than the $4 block rate, but the scheduled project requires more cash under the monthly option.

Move that same project entirely inside one billing period and the comparison changes: the 30 GB allowance would need another 6 GB, so its top-up price becomes decisive. That is why multiplying total demand by the cheapest displayed rate is not enough. Model the work against renewal dates, purchase increments, and any expiry date for extra traffic.

A remaining allowance helps with later work only while it remains usable under the account's conditions. Separate traffic expiry from subscription renewal and from any requirement to keep the account active. If base traffic and purchased additions have different validity periods, establish which balance is used first; the answer can affect what expires unused.

The selected configuration also belongs in the price. Access to a particular network, finer location selection, reserved addresses, or other features can change the charge. If a tariff uses a consumption multiplier, keep physical bytes and charged units distinct. Apply the multiplier only if the usage figure has not already applied it. The same care is needed with minimum commitments, the rate for additional traffic, and taxes included or excluded from the quote.

For regular heavy work, compare the full planned workload with an appropriate fixed-price option. The alternative must meet the same requirements for sites, locations, sessions, permitted traffic, and delivery speed. A fixed fee can make large transfers easier to budget, while traffic-based access can avoid maintaining capacity that an occasional task rarely uses. Neither billing unit establishes which network will work better.

Recover from failures without buying the same work again

Recovery should begin at the smallest unfinished part of the task. If a run has already stored most of its documents, restarting the entire list can purchase many identical downloads. Record completed identifiers, validate saved files, and resume the remaining queue. This reduces waste without changing the proxy network or its price.

Interrupted large files need a more specific mechanism. Where the server and client support range requests, a download can request the missing portion. The client must verify that it is continuing the same version of the file. A 206 Partial Content response supplies a range; a full 200 OK response must not be blindly appended to an existing fragment. Resume support can save transferred bytes, but it has to be implemented correctly.

Errors should lead to different decisions. A temporary connection failure may justify a bounded retry. A repeated refusal, expired login, exhausted account allowance, or invalid request needs a different response. Rapidly repeating an unchanged problem can spend more while making no progress. For actions that change a remote account, establish whether the first attempt completed before submitting it again.

The fact that a task failed does not erase bytes already transferred. An interrupted download or a rejection page can consume paid traffic; some services exclude their own connection errors. Apply the terms for the actual proxy product rather than borrowing a successful-request billing promise from a scraping API.

Session continuity can affect recovery too. Replacing an IP may invalidate a workflow tied to that session and require earlier steps again. Holding an IP may preserve continuity, but it does not make later transfers free or guarantee that the website session will stay valid. Save progress where possible and choose the recovery action that addresses the failure.

Keep a running job inside its budget

Watch progress alongside usage. Three useful readings are the remaining allowance, recent consumption per minute, and completed tasks over that same interval. If usage rises while completions stall, the job needs attention before the balance is exhausted. If both rise proportionally, the application may simply be doing more work.

For example, 14 GB remaining at a sustained 0.35 GB per minute provides about 40 minutes of traffic at that rate. This is a planning estimate, not a shutdown guarantee: the rate may change, displayed usage may lag, and active transfers may still be completing. Compare that time with the remaining queue and stop or reduce new work early enough to finish safely.

Use controls at both the purchase and application levels. On the account, choose deliberately whether depletion stops access or authorizes another purchase or an overage charge. In the application, bound the queue, attempts, simultaneous transfers, and duration of open sessions. An automatic refill keeps the connection funded; it cannot decide whether the work still deserves the money.

Long-running downloads and media sessions need an explicit stopping condition. Merely starting fewer new requests may leave existing transfers consuming data. The application should be able to cancel ongoing work and close unused sessions. Keep headroom for reporting and enforcement delays instead of treating a dashboard threshold as an instantaneous switch.

When the numbers look wrong, reconcile one bounded run. Match the account or user, time interval, unit, and task log. Browser network tools help locate heavy transfers and distinguish transferred from unpacked resource sizes, but they do not necessarily cover every process using the account. Track traffic consumption separately from purchases, balance transfers, and expiry; a balance change is not always a network transfer.

Then make one targeted change and repeat the same task. Preserve the browser state the test needs, avoid duplicate downloads, retain supported compression, and prevent irrelevant resources from starting where that does not break the workflow. The result should show both lower spending and successful completion. A transfer reduction that removes the evidence the task was meant to collect is an incomplete job.