Proxy Bandwidth vs IP Count: Pricing Models

Proxy providers price access in two fundamentally different ways: by the gigabyte of bandwidth consumed, or by the number of IP addresses (or ports) you hold. Each model rewards a different type of workload, and choosing the wrong one can result in a bill two or three times higher than necessary. This guide explains both models, works through practical examples, and covers the hidden costs that are easy to miss in a pricing comparison.

Updated August 2026 to reflect current LocalProxies pricing and plan structure.

The Two Main Proxy Pricing Models

Almost every proxy pricing structure is a variation of one of two underlying models:

• Bandwidth-based pricing: you pay per gigabyte of data transferred through the proxy, regardless of how many IPs you use or how many requests you make.
• IP-count-based pricing: you pay for a fixed number of IP addresses (or ports, or threads), typically on a monthly subscription, regardless of how much data you transfer through them.

Some providers offer hybrid models that combine elements of both, and a small number price per request rather than per byte. We cover those variations below.

	Bandwidth-based	IP-count-based
Unit you buy	Gigabytes of transfer	IPs, ports, or threads (flat monthly)
Provider cost driver	Variable traffic (data volume)	Fixed infrastructure (IP leases, server slots)
Best for	Variable or low-payload workloads, high IP diversity, rotating residential	High request volume on few IPs, static or persistent IPs, predictable flat cost
Weak for	Very high sustained transfer, or guaranteed static IPs	Low-volume or bursty use (you pay for idle IPs), broad IP diversity
Typical of	Residential proxy networks	Datacenter and ISP or static-residential proxies

For context on what you are actually buying under each model, our guide to what a residential proxy is and our comparison of residential vs datacenter proxies explain the underlying infrastructure.

How Bandwidth-Based Pricing Works

Under bandwidth-based pricing, every byte that passes through the proxy gateway is metered. You purchase a pool of gigabytes (say, 10 GB, 50 GB, or 500 GB) and draw it down as you use it. When the pool is exhausted, you either pay for an overage, top up, or stop until the next billing cycle.

Bandwidth-based pricing is the dominant model for residential proxy networks, where access is sold by the gigabyte of traffic rather than by the IP.

What counts toward your bandwidth?

This varies by provider, but the common approaches are:

• Egress only: only data sent from the proxy to the target server counts. Response data (downloads) does not count or counts at a lower rate. This model benefits use cases that send large requests but receive small responses.
• Total transfer: both upload and download count. This is more common and more predictable. If you request a 500 KB page, 500 KB (plus request overhead) is metered.
• Failed requests: some providers count bandwidth on blocked or failed requests; others do not. This can significantly affect cost when your target site has aggressive blocking.

LocalProxies meters total transferred data (upload and download combined). Bandwidth starts at $3.00/GB and steps down to $2.10/GB as volume increases; see the setup tutorial for plan details or the FAQ for billing specifics.

How IP-Count-Based Pricing Works

Under IP-count-based pricing, you pay a flat monthly fee for access to a defined number of IP addresses or concurrent connection ports. Transfer through those IPs is either unlimited or subject to a very high soft cap.

This model is common for datacenter proxies and ISP proxies (hosted static residential IPs) because the provider’s underlying cost is fixed infrastructure (server slots, IP block leases) rather than variable traffic. A datacenter IP sitting idle costs the provider almost the same as one under heavy load. Per-IP pricing is therefore specific to datacenter and static-residential (ISP) proxies, where each IP is a fixed, dedicated resource; rotating residential networks, LocalProxies included, price per gigabyte instead.

Variants of IP-count pricing

• Per-IP subscription: you pay $X/month per dedicated IP. Common for static residential and ISP proxies where each IP is exclusively yours.
• Per-port (thread) subscription: you pay for a number of concurrent connection slots into a shared IP pool. Each port can open one connection at a time; holding 10 ports means 10 simultaneous requests. This is the typical model for shared datacenter proxy plans.
• Per-subnet: you lease an entire IP block (e.g., a /24 with 256 addresses) at a fixed monthly rate. Used primarily for large-scale operations that need IP diversity within a single autonomous system.

Hybrid and Per-Request Models

Not every provider fits neatly into one bucket, and two variations are common enough to plan around.

Hybrid (concurrency plus bundled bandwidth). Many residential providers sell tiers defined by concurrency (ports or threads) that each include a bandwidth allotment, then charge per-GB top-ups for anything beyond it. You are provisioned by concurrency but billed by data. This is how LocalProxies is structured (covered below): you pick a Ports or Threads tier, it comes with bandwidth at a per-GB rate that falls with volume, and you top up if you exceed the allotment.

Per-request pricing. A smaller set of providers, usually “web unblocker” or SERP-API products, charge per successful request instead of per byte. The price bundles the proxy, retries, CAPTCHA handling, and often parsing into one number. It is predictable per request and convenient, but at high volume it is usually the most expensive option, because you pay for the managed layer whether or not your target needed it.

Which Model Costs Less for Your Use Case?

The answer depends on two variables: how much data each request transfers, and how intensively you use each IP.

The worked examples below price the two pure models to build intuition. The per-port and per-IP figures are illustrative market rates, not quotes, and a hybrid provider like LocalProxies bills by bandwidth but still provisions by concurrency, so a real quote there depends on both your throughput and your data.

Worked examples

Example A: Light scraping with large page sizes (e-commerce catalog). You scrape 50,000 product pages per month. Each page response averages 300 KB. Total data: 50,000 × 300 KB = 15 GB/month.

Under a residential bandwidth rate of about $3.00/GB, the data costs about $45/month. Under IP-count pricing, if you need only 5 concurrent threads and the plan costs an illustrative $8/port/month, the total is $40/month: slightly cheaper, though it caps you at 5 simultaneous connections.

In this scenario the two models land close together. Bandwidth pricing is competitive when payloads are large, but it pulls clearly ahead only once your per-GB rate drops at volume; if you need guaranteed concurrency on a fixed IP set, IP-count pricing can edge ahead.

Example B: High-frequency, low-payload monitoring (price checks). You check 500,000 product prices per month. Each response is 8 KB (a structured JSON endpoint, not a full HTML page). Total data: 500,000 × 8 KB = 4 GB/month.

Under bandwidth pricing at $3.00/GB: approximately $12/month. Under IP-count pricing with 20 ports at $8/port/month: $160/month, dramatically more expensive for the same task. The pure bandwidth model is clearly better here, though a hybrid provider would still charge for the 20-thread concurrency tier this workload needs.

Example C: Account management requiring static IPs. You manage 50 accounts on a platform, each needing a consistent IP to avoid triggering security alerts. You make modest traffic (perhaps 1 GB total per month across all accounts).

Under bandwidth pricing at $3.00/GB: approximately $3/month, but you cannot guarantee IP persistence across sessions. Under IP-count pricing, 50 dedicated static IPs at $5/IP/month: $250/month; expensive, but you get guaranteed IP consistency.

Here, the technical requirement (static IPs) makes IP-count pricing necessary regardless of cost. The question becomes whether static residential or datacenter IPs are needed. For AI agent workflows that maintain persistent sessions, see our guide to AI agent proxy use cases.

Example D: Large-scale web scraping (news aggregation, market research). You process 2 million pages per month with an average response size of 120 KB. Total: 2,000,000 × 120 KB = 240 GB/month.

Under bandwidth pricing at $2.40/GB (the rate near this volume, easing toward $2.10/GB at 1 TB): approximately $576/month. Under IP-count pricing with 200 ports at $8/port/month: $1,600/month. Bandwidth pricing wins significantly at scale for high-volume scraping. See our scraping use case guide for more context: web scraping proxies.

Pricing for Agent Workloads

Autonomous agents make traffic bursty and unpredictable: an agent workload may sit idle, then spike. Flat IP-count plans force you to provision for the peak and pay for the idle time, while bandwidth pricing charges only for what actually flows, which suits variable agent traffic.

For a deeper look at agent-specific patterns, see our AI agent proxy use cases.

Hidden Costs: Overages, Minimums, and Session Fees

The headline rate is rarely the full picture. These are the most common additional costs to factor in:

Bandwidth overages

Many bandwidth plans include a base pool and charge a higher per-GB rate for usage beyond it. Overage rates are often 1.5 to 3x the base rate. If your workload is unpredictable, this can make bandwidth plans expensive. Check whether the provider allows you to cap usage (and refuse requests once the cap is hit) rather than silently accumulating overages.

Minimum commitments

Both model types frequently have monthly minimums: either a minimum data purchase (e.g., 10 GB minimum regardless of use) or a minimum number of ports/IPs. For small or early-stage operations, minimums can make a plan structurally expensive even if the per-unit rate is low.

Session and rotation fees

Some bandwidth-based providers charge an additional fee per session opened, per IP rotation event, or per sticky session maintained beyond a base time. If you open millions of short sessions, these can exceed the bandwidth cost itself. Ask explicitly whether session management has separate pricing.

Failed request billing

If a provider counts bandwidth on blocked or errored requests, your effective cost per successful request is higher than the headline rate implies, especially on targets with aggressive bot detection. This is most relevant for large-scale scraping workflows.

Setup and API fees

Some providers charge for dashboard API calls, sub-user creation, or advanced features like ISP-level targeting. These are rarely listed prominently.

How to Estimate Your Monthly Proxy Spend

A reliable estimate requires three numbers:

1. Request volume: total requests per month.
2. Average response size: sample 50 to 100 real responses from your target and measure the average payload size in KB. Do not use the HTML source size. Include images, scripts, and other assets if your scraper loads them, or use only the HTML size if you are making targeted API-style requests.
3. Success rate: if 15% of requests fail and you are billed for failed bandwidth, your effective cost per successful request is ~18% higher than the headline rate implies.

Calculation formula for bandwidth-based pricing:

Monthly cost = (requests × avg_response_KB / 1,000,000) × GB_rate × (1 / success_rate)

For IP-count pricing:

Monthly cost = concurrent_threads_needed × port_rate + (any overage GB × overage_rate)

The number of concurrent threads needed is determined by your target throughput and the latency per request. If each request takes 2 seconds and you need to process 3,600 requests per hour (1 per second), you need at minimum 2 concurrent threads, but in practice, you want headroom, so 5 to 10 threads for that workload.

For a more detailed treatment of how many IPs different workload sizes actually require, see our guide on how many IPs you need for web scraping.

How LocalProxies Approaches Pricing

LocalProxies is a hybrid: you buy a concurrency tier, and it includes bandwidth priced per gigabyte. Two plan families cover the two main workload shapes:

• Sticky sessions, sold by Ports (1 to 50), where each port holds one concurrent connection and the IP persists for 10 minutes or more. Best for multi-step, session-bound work.
• High rotation, sold by Threads (40 to 650), where every request can exit through a new IP. Best for large-scale, parallel collection.

Every tier includes a bandwidth allotment at a per-GB rate that falls with volume, from $3.00/GB at entry to $2.10/GB at the top, and you can buy bandwidth top-ups (10 GB to 1 TB, on the same curve) if you exceed it. So you provision by concurrency but you are billed by data, which keeps small, bursty workloads cheap and large ones predictable.

A few specifics worth knowing:

• Bandwidth is metered on total data transfer, upload and download combined.
• If you exceed your pool, buy a top-up from 10 GB to 1 TB on the same per-GB curve, applied instantly from your members panel with no plan change; unused gigabytes roll over rather than expiring.
• Both authentication methods are included at no extra cost: IP whitelisting and username/password. The plan’s Auth-IP allowance (4 to 25 addresses depending on tier) is a whitelist quota, not a per-IP charge, so you are billed for bandwidth, not for how you connect.

To size a plan, estimate your monthly data with the formula above, then pick the Ports or Threads tier that covers both your concurrency and that bandwidth. See pricing for the full ladder, the FAQ for billing mechanics, or request a trial to measure real consumption first. For a full walkthrough of how our pricing works, see How LocalProxies Pricing Works.

The right pricing model is the one that matches your workload structure, not the one with the lowest headline number. Running the calculation above against your actual request volume and response sizes will give you a reliable basis for comparison across any provider’s pricing page.