Proxy Pricing Explained: Per IP vs Per GB and Cost per Successful Request

What per-IP and per-GB pricing mean

Per-IP pricing charges for an allocated number of proxy addresses over a billing period. Your monthly package cost depends on the quantity and plan. Unused addresses still contribute to the bill, so buy around the identities and capacity your workflow needs.

Per-GB pricing charges for metered traffic. Ask which bytes count: downloads, uploads, failed responses, retries and any protocol overhead. Also check the minimum commitment, credit expiry, overage price and whether the provider uses decimal GB or another unit.

Billing and network type are separate choices. Datacenter versus residential describes the network; dedicated versus shared describes allocation; static versus rotating describes identity behavior. None of those labels alone tells you whether a plan charges per IP or per GB. See dedicated versus semi-dedicated proxies and static versus rotating proxies before comparing quotes.

Read package prices correctly

The BuyProxies homepage, checked on October 2, 2026, lists these smallest monthly packages in USD, before applicable taxes:

The $2.50 and $1.25 figures are unit averages within those packages, not the checkout totals or a promise that one IP can be purchased at that price. Dedicated IPs are exclusive to your account; semi-dedicated IPs are shared by up to three users.

Both packages advertise unlimited bandwidth. That does not guarantee unlimited throughput, unlimited concurrency or successful access to every destination. A predictable bill still needs a pilot that verifies response quality and completion time. Confirm current terms and your selected package in the order form.

Calculate cost per successful, useful response

Define success before measuring it. For a product-monitoring job, success might mean the expected product identifier, price and currency were parsed and stored. A status 200 containing an error page is not useful. A duplicate response from a retry does not create another completed job.

Proxy cost per useful response = proxy charges for the measurement period ÷ successful useful responses in that period. Multiply by 1,000 to express the result per 1,000 useful responses. Use the same period and success criteria for every candidate.

For metered traffic, reconcile your client logs with the provider’s billing meter. A response-body counter may omit paid uploads, failed transfers or other counted traffic. Retries can add billable egress without adding useful results. For a fixed package, allocate the full period’s charge, including idle time; do not count only the busy hours.

You can also calculate total workflow cost by adding compute, storage and operational support. Keep that number separate from proxy-only cost so another team can reproduce the comparison.

Worked example: small JSON, HTML and media

The $5/GB rate below is invented for illustration. It is not a BuyProxies tariff or a competitor offer. Assume 10,000 useful responses require 12,000 total attempts. Every attempt averages the stated billable bytes, including any counted request and response traffic. Use decimal units: 1 GB = 1,000,000,000 bytes.

For the HTML row: 12,000 × 250,000 ÷ 1,000,000,000 = 3 GB; 3 × $5 = $15; $15 ÷ 10,000 × 1,000 = $1.50. The 2,000 additional attempts consume traffic even though they produce no additional useful responses.

If a $12.50 monthly fixed package actually completes those same 10,000 useful responses within the month, its proxy cost is $1.25 per 1,000. That assumes it meets the workload’s routing, identity and timing requirements. The arithmetic does not demonstrate equivalent networks or destination acceptance.

Under the invented $5/GB rate, $12.50 corresponds to 2.5 GB. This is a spending crossover only, before minimum commitments or taxes. It is not a universal purchasing threshold.

A lower GB rate can still cost more per result

Consider two more invented scenarios, not provider offers. Scenario A bills 2 GB at $5/GB and returns 8,000 useful responses: $10 total, or $1.25 per 1,000. Scenario B bills 3 GB at $3/GB and returns 4,000 useful responses: $9 total, or $2.25 per 1,000. B has the lower GB rate and bill, but the higher cost per completed result.

Run a small pilot before buying capacity

1. Choose representative jobs. Include normal payloads, peak hours and the destinations you are authorized to access.
2. Record the contract. Note package quantity, period, taxes, metering rules and replacement or renewal conditions.
3. Measure useful completions. Record attempts, billed traffic, response validation, latency and retry reasons. Separate proxy authentication problems from API authorization or rate-limit failures.
4. Project a realistic month. Include idle capacity, growth and heavier payloads. Use observed completion rates rather than a promised request count.
5. Scale the suitable route. A stable identity requirement may justify dedicated capacity even for small payloads; see static proxy IPs for API allowlists.

Use the proxy tester for an initial connectivity check, then verify your real application. Consult the authentication guide and API testing guide when interpreting failures. Keep retries bounded and follow the API’s retry rules; HTTP’s idempotency guidance explains why automatically repeating a write can be unsafe.

View dedicated proxy packages or view semi-dedicated packages, then test a small package against your success criteria.

Frequently asked questions

Is per-IP pricing always cheaper?

No. A lightly used package can have a high cost per useful response. Metered traffic can suit a small workload, depending on commitments and actual acceptance.

Do unsuccessful requests cost money?

That depends on the billing contract. Measure whatever failed or retried traffic the provider counts. A fixed package still has its period charge when requests fail.

Does unlimited bandwidth mean unlimited speed?

No. Bandwidth allowance, transfer rate and simultaneous connections describe different constraints. Verify capacity with your application.

Should I count every HTTP 200 as a success?

No. Validate the expected response content and count useful completed jobs once. Otherwise empty results and duplicate retries distort your comparison.