Proxy pricing looks arbitrary until you realize the model itself encodes assumptions about how you're supposed to use the product. Pick the wrong one and you're not just overpaying — you're fighting the pricing structure on every request.
Per-GB (bandwidth-based)
You pay for data transferred, and the IP pool is effectively unlimited. Standard for residential and mobile proxies.
Works well when: each request returns a small payload. Scraping text-heavy pages, checking prices, verifying ad placements — high request counts, low bytes per request. You get access to a huge pool without paying for IPs you touch once.
Gets expensive fast when: your targets return heavy pages. A modern e-commerce page with images and video assets can easily be several MB, and if you're not blocking media at the request level, you're paying real money to download product photos you never look at.
The optimization nobody does on day one: block images, fonts, video and stylesheets in your HTTP client or headless browser config. On image-heavy targets this routinely cuts bandwidth by well over half, which on a per-GB plan is a direct, immediate cost reduction with no downside for text extraction.
Per-IP (allocation-based)
You rent a fixed set of IPs for a period, and bandwidth through them is unmetered or generously capped. Standard for datacenter and ISP proxies.
Works well when: you have predictable, sustained volume against a known set of targets, and especially when payloads are heavy. Once you've paid for the IP, downloading 10 MB costs the same as downloading 10 KB.
Gets expensive fast when: your usage is bursty or exploratory. Paying monthly for 50 IPs you use for three days of a campaign is pure waste, and this is the most common way teams overspend without noticing — the bill is flat, so nothing signals that utilization collapsed.
Watch for: the difference between "unlimited bandwidth" and "unlimited bandwidth subject to fair use." Read what the actual throttle threshold is before building a pipeline that assumes the former.
Per-request (API-style)
You pay per successful request, and the provider handles rotation, retries and often rendering. This is the unblocker/scraping-API model rather than raw proxy access.
Works well when: you value not maintaining the infrastructure more than you value per-unit cost. It's genuinely the cheapest option at low volume once you price in engineering time.
Gets expensive fast when: volume grows. The per-unit cost that felt trivial at 10k requests/month becomes the dominant line item at 10M, and by then you've built everything around their abstraction rather than around a proxy layer you control.
The lock-in worth naming: this model usually means you don't have direct IP access, so migrating away later means rebuilding the rotation, retry and session logic the provider was handling for you.
Doing the actual math
Work out cost-per-successful-request under each model for your real traffic, not your ideal traffic:
per_gb_cost = (avg_payload_mb / 1024) * price_per_gb / success_rate
per_ip_cost = (monthly_ip_cost * ips_needed) / monthly_successful_requests
per_request_cost = price_per_request
The success_rate divisor matters more than people expect. A cheaper pool with a 60% success rate can easily cost more per successful request than a pricier pool at 95%, because you're paying for the failures too — on a per-GB plan, a blocked response still transfers bytes.
Mixing models on purpose
There's no rule saying you pick one. A common mature setup: datacenter per-IP for high-volume low-defense targets, residential per-GB for the subset of targets that need it, and neither for anything you can get from an official API. Routing each target to the cheapest model that actually works for it is usually a bigger cost lever than negotiating rates within any single model — it's the thing we most often end up working through with teams sizing infrastructure on SotaProxy, since the answer is almost always a mix rather than one plan.
The failure mode to avoid is picking a model once, at the start, when your traffic pattern was hypothetical — and never revisiting it after you learned what your traffic actually looks like.
Top comments (0)