Every large scraping operation eventually runs into the same wall. The workload requires residential IPs, because the targets block anything that looks like hosting infrastructure. But the volume is enormous, and residential proxies are billed by the gigabyte. The result is a monthly invoice that scales linearly with ambition, and an engineering team that spends more effort minimising bytes than improving data quality.
Unlimited residential proxies exist to remove that wall. Instead of paying for data consumed, you pay for throughput — sustained bandwidth measured in megabits per second. Your speed is capped; your volume isn't. The meter stops running.
This guide covers how bandwidth-based pricing actually works, exactly where the break-even sits against per-gigabyte plans, what you give up in exchange, how to size a plan properly, and how to saturate throughput you've already paid for instead of leaving half of it idle.
What Unlimited Residential Actually Means
The phrase is marketing, so it's worth being precise about what's unlimited and what isn't.
What's unlimited: total data transferred. There is no gigabyte allowance, no overage charge, and no meter to watch. You can move a terabyte or ten and the bill doesn't change.
What's limited: how fast you can move it. You purchase a specific throughput ceiling — commonly expressed in megabits per second — and your aggregate traffic across all concurrent connections cannot exceed it. Buy 100 Mbps and you get 100 Mbps, continuously, forever.
So the product isn't unlimited in the sense of unconstrained. It's unmetered, with the constraint moved from volume to rate. That's a genuinely different shape, and it changes both your cost model and your engineering priorities.
Working out what a throughput tier actually delivers
The arithmetic is worth doing explicitly, because most people have no intuition for converting Mbps into pages.
A 100 Mbps connection running continuously for a month:
12.5 MB/s x 86,400 s/day = ~1,080 GB/day
1,080 GB x 30 days = ~32 TB/month at full saturation
Thirty-two terabytes. Compare that against any per-gigabyte rate you've been quoted and the reason this product exists becomes immediately obvious.
The catch, and it's a large one: that figure assumes 100% saturation, which nobody achieves. Real-world utilisation depends on how efficiently your crawler keeps the pipe full, and most operations run at somewhere between 20% and 60% of their purchased ceiling. At 40% utilisation, that 100 Mbps plan delivers around 13 TB a month — still enormous, but less than half the headline figure.
This is the single most important thing to understand about the product: you're buying capacity, and unused capacity is wasted money. Everything in the operational section of this guide is about raising utilisation.
How the Networks Differ from Standard Residential
Unlimited residential is not simply the same network on a different billing plan. The infrastructure is usually distinct, and the differences matter.
Smaller IP pools. Standard rotating residential networks advertise tens of millions of addresses. Unlimited residential pools are typically much smaller — often in the low millions. That's still large in absolute terms, but it means less IP diversity per request and a higher chance of repeat addresses on a given target.
Concentrated infrastructure. Bandwidth-based products often route through a limited set of gateway locations rather than being globally distributed. This matters for latency: if the gateways sit in North America and your targets are in Southeast Asia, every request pays a round-trip penalty that a distributed network wouldn't impose.
Coarser geographic targeting. Country and sometimes city or ASN targeting is usually available, but the granularity and coverage tend to be narrower than the flagship per-GB pool. Verify the specific markets you need rather than assuming parity.
Unlimited concurrent connections. This is normally included, and it's essential — you cannot saturate a large throughput allowance with a small connection count.
Optimised for sustained load. The infrastructure is built for continuous high-volume ingestion rather than bursty consumer-scale usage, which generally makes it more stable under exactly the conditions that would strain a standard pool.
The honest summary: you trade IP diversity and geographic reach for volume economics. If your workload needs to look like a hundred thousand different people in forty countries, this is the wrong product. If it needs to ingest enormous quantities of data from residential-classified addresses, it's the right one.
Where the Break-Even Actually Sits
This is the calculation that should drive the entire buying decision, and very few people run it properly.
Step one: estimate real consumption
The success rate divisor is the part everyone forgets. You pay for the bandwidth of a failed request exactly as you pay for a successful one. At a 50% success rate you're funding twice the traffic you get usable data from.
Work an example. Five million requests a month, a 70% success rate, an average response of 250 KB:
Step two: price both models
Unlimited cost = flat monthly price for your chosen throughput tier
Step three: check the throughput tier can actually carry it
This step gets skipped constantly, and skipping it is how people buy an unlimited plan that can't do the job.
For 1,786 GB at a realistic 40% utilisation:
So this workload needs roughly 14 Mbps of purchased throughput at realistic utilisation — and if the smallest available tier is well above that, the unlimited plan may be more expensive than per-GB billing despite the enormous headline capacity.
The general shape of the answer
- Under a few hundred gigabytes a month: per-GB billing almost always wins. Unlimited plans have a floor price that dwarfs small consumption.
- Low terabytes: it depends entirely on your per-GB rate and the entry throughput tier. Run the numbers both ways.
- Above several terabytes: unlimited wins, usually by a large margin, and the margin widens as volume grows.
- Spiky traffic: per-GB wins, because you only pay for what you use. Unlimited charges you for idle capacity.
- Continuous traffic: unlimited wins, because sustained load is exactly what throughput pricing rewards.
> Tip: Measure average response size on a sample of a few hundred real requests before committing. Almost everyone guesses low, frequently by a factor of two or three, and the error propagates straight into a wrong purchasing decision.
When Unlimited Residential Is the Right Choice
Reach for bandwidth-based pricing when:
- Volume is in the terabytes and continuous. This is the core case and the reason the product exists.
- You're building training corpora or large datasets. Machine learning data collection has exactly the profile that suits this model — sustained, enormous, and mostly raw content rather than tidy fields.
- You're running full-catalogue price or product intelligence. Monitoring hundreds of thousands of SKUs continuously produces steady, predictable, very large traffic.
- You're crawling large sites exhaustively rather than sampling.
- You use headless browsers heavily against protected targets. Browsers load every asset and multiply bandwidth by an order of magnitude. On per-GB billing this is punishing; on unmetered throughput it's free.
- Bandwidth anxiety is distorting your engineering. If your team is spending significant effort shaving bytes rather than improving coverage or data quality, the meter is costing you more than it appears to.
- You need predictable costs. A flat monthly figure is far easier to budget and defend internally than a consumption line that varies with how ambitious your crawl was.
When Unlimited Residential Is the Wrong Choice
Don't buy it when:
- Your volume is modest. Below a terabyte or so, per-GB is nearly always cheaper. Paying a large flat fee to move 200 GB is straightforwardly bad economics.
- Traffic is spiky or seasonal. You pay for the capacity whether or not you use it. A workload that runs hard for three days a month wastes most of the plan.
- You need broad geographic granularity. Smaller pools and more concentrated infrastructure mean narrower targeting. If your data depends on city-level accuracy across many markets, use the standard residential pool.
- You need maximum IP diversity. Smaller pools mean more address reuse per target.
- Latency is critical. Concentrated gateway locations add round-trip time for distant targets.
- The target doesn't require residential classification. If datacenter proxies work, unmetered datacenter bandwidth is dramatically cheaper than unmetered residential throughput. Test the cheap tier first, always.
That last point deserves emphasis. The most expensive mistake available here is buying unmetered residential throughput for a workload that unmetered datacenter bandwidth would have handled. Run five hundred requests through datacenter IPs against your real target before considering anything else.
Sizing a Plan Properly
Getting the tier right is the difference between a good purchase and an expensive one.
Start from measured data, not estimates. Run a representative sample of your workload on a per-GB plan or a trial and record: total bytes transferred, request count, success rate, and average response size. Guessing at these numbers produces sizing errors of several hundred percent.
Assume realistic utilisation. Plan for 40–50% saturation unless you already know your crawler keeps a pipe full. Sizing at 90% utilisation and achieving 35% means buying a plan that can't do the job.
Size for sustained load, not peak. Throughput plans reward steady utilisation. If you have bursts, flatten them by spreading work across the full day rather than buying a tier that accommodates a two-hour spike.
Account for growth. Upgrading mid-cycle is usually possible but rarely instant. Leave headroom.
Check the concurrency policy. Unlimited concurrent connections is normal, but confirm it. A throughput allowance you can't parallelise into is unusable.
Verify the geographies before committing. Confirm the specific countries and cities you need are actually available on the bandwidth-based product, not just on the provider's flagship pool.
Reading a Bandwidth Plan's Fine Print
Throughput products have more variation in their terms than any other proxy category, and the differences are frequently worth more than the price gap.
- Is the ceiling a hard cap or a fair-use threshold? A hard cap throttles you cleanly at the purchased rate. A fair-use policy may allow bursting above it, or may quietly degrade you for sustained heavy use. Ask which.
- Is throughput measured per gateway or in aggregate? If it's per gateway and you're spreading across several, your effective total may be higher or lower than the headline number suggests.
- Are concurrent connections genuinely unlimited? Some plans advertise unlimited concurrency and enforce a ceiling in practice. You'll find out under load, which is the wrong time.
- Is the pool shared with the per-GB product or separate? Separate infrastructure usually means smaller pools; shared usually means better diversity but more contention.
- What's the minimum contract term? Bandwidth plans commonly commit you for longer than per-GB plans, because the provider is reserving capacity.
- Can you upgrade or downgrade mid-cycle, and at what cost? Sizing errors are common; the ability to correct them matters.
- Is billing daily, monthly, or prepaid? Daily billing on throughput products is more common than people expect and changes the arithmetic on short campaigns considerably.
- What happens if you exceed the rate? Throttling, queuing, or overage charges are all used, and they behave very differently under a crawler that doesn't know it's being limited.
None of this is exotic — it's the sort of thing that's clear in the terms and invisible in the marketing. Read it before committing, because the commitment is usually longer here than elsewhere.
Setting Up Unlimited Residential
The sequence that catches problems earliest:
- Get your gateway, port, and credentials from the dashboard.
- Choose an authentication method — IP whitelisting or username/password. Credentials are usually required if you're encoding targeting parameters.
- Test with a single curl request before touching real tooling.
- Verify the exit IP and its classification.
- Verify geo-targeting returns the country you asked for.
- Measure achievable throughput before building anything on top of it.
- Then integrate and scale up gradually.
Connectivity:
Classification and geography:
Check that org and asn name a consumer ISP and that the location matches your request.
Measuring achievable throughput
This is the step specific to bandwidth-based products, and it's the one that tells you whether the plan will actually work.
curl -x http://USER:PASS@GATEWAY:PORT \
-o /dev/null -w "%{speed_download} bytes/sec\n" \
--max-time 60 \
https://example.com/large-test-file
Run it with increasing parallelism and watch where aggregate throughput plateaus. That plateau, not the number on the invoice, is your real ceiling. If it sits well below what you purchased, the cause is usually your own client configuration rather than the provider — see the saturation section below.
Integration by Tool
Python — high-concurrency async
Bandwidth-based plans demand concurrency. A synchronous crawler will not saturate a large allowance no matter how long it runs.
PROXY = "http://USER:PASS@GATEWAY:PORT"
SEM = asyncio.Semaphore(200)
async def fetch(session, url):
async with SEM:
try:
async with session.get(url, proxy=PROXY, timeout=aiohttp.ClientTimeout(total=45)) as r:
return url, r.status, await r.read()
except Exception as e:
return url, None, None
async def main(urls):
conn = aiohttp.TCPConnector(limit=0, limitperhost=20)
async with aiohttp.ClientSession(connector=conn) as s:
return await asyncio.gather(*(fetch(s, u) for u in urls))
Note limit=0 on the connector, which removes aiohttp's default connection cap. Leaving that default in place is one of the most common reasons people can't saturate a plan they've paid for.
Scrapy
CONCURRENT_REQUESTS = 300
CONCURRENTREQUESTSPER_DOMAIN = 20
DOWNLOAD_TIMEOUT = 45
REACTORTHREADPOOLMAXSIZE = 40
RETRYHTTPCODES = [403, 429, 500, 502, 503, 504]
AUTOTHROTTLE_ENABLED = False
Turn AUTOTHROTTLE off deliberately here. It's designed to be polite by backing off, which is exactly the opposite of saturating purchased throughput. Manage politeness with per-domain concurrency limits instead, so you stay considerate to individual sites while keeping the aggregate pipe full.
Node
const agent = new HttpsProxyAgent({
host: 'GATEWAY', port: PORT,
auth: 'USER:PASS',
keepAlive: true,
maxSockets: 500
});
keepAlive and a high maxSockets matter enormously. Connection setup overhead at high request rates can consume a meaningful fraction of your effective throughput.
Playwright and Puppeteer
proxy: { server: 'http://GATEWAY:PORT', username: 'USER', password: 'PASS' }
});
This is the product where headless browsers stop being financially painful. On per-GB billing, letting a browser load every image, font, and tracking script is a costly indulgence. On unmetered throughput it's free, and full asset loading produces a substantially more realistic traffic profile — which often improves success rate as a side effect.
Run many browser contexts in parallel rather than many pages in one context, and cap contexts by available memory rather than by bandwidth concern.
Saturating What You Bought
This is where unlimited residential succeeds or fails as an investment. Idle capacity is money burned, and most operations leave half their purchase unused.
Raise concurrency aggressively. Throughput plans normally include unlimited concurrent connections. A crawler running fifty parallel requests will not fill a large pipe. Push into the hundreds and measure.
Remove default connection limits. Nearly every HTTP library ships with a conservative connection pool cap. aiohttp, requests' underlying adapter, Node's agent, and Scrapy's reactor all have defaults that will silently throttle you far below your purchased ceiling.
Use keep-alive everywhere. Opening a new TCP connection and completing a TLS handshake for every request wastes both time and bandwidth. Connection reuse can improve effective throughput substantially at high request rates.
Parallelise across targets, not within them. Politeness to individual sites and aggregate saturation aren't in conflict. Cap per-domain concurrency at a respectful level and run many domains simultaneously.
Eliminate serial bottlenecks. If your parser, your database writes, or your deduplication logic runs synchronously in the request path, they become the limiting factor rather than bandwidth. Decouple fetching from processing with a queue.
Monitor actual throughput continuously. Instrument bytes per second in aggregate and compare against your purchased tier. If you're at 25% utilisation you're paying four times what your data costs, and the fix is almost always in your client rather than the provider's network.
Batch your work to run continuously. Throughput plans reward steady load. Spreading a job across twenty-four hours uses the same capacity you've already bought; compressing it into two hours means paying for twenty-two idle ones.
Stop optimising for bytes. This is the mindset shift the product enables and the one people forget to make. Full page loads, generous retry policies, redundant fetches for reliability, keeping raw responses instead of parsing on the fly — all the things that were expensive under per-GB billing are now free. Take advantage of them.
> Tip: Store raw responses rather than parsing in the request path. Re-crawling to fix a parser bug is expensive in time even when bandwidth is free, and disk is cheaper than either.
Troubleshooting
Symptoms and their usual causes:
- Throughput far below your purchased tier — almost always client-side. Check library connection pool limits, concurrency settings, keep-alive, and whether a synchronous parser is blocking the fetch loop.
- Throughput plateaus regardless of concurrency — you've hit either the purchased ceiling or a bottleneck downstream. Instrument each stage separately to find out which.
- High latency on distant targets — expected. Bandwidth-based products often route through concentrated gateway locations. If your targets are far from those gateways, this is structural rather than fixable.
- Repeat IPs on the same target — smaller pool. Widen your target spread or accept more repetition; if IP diversity is critical, the standard residential pool is the better product.
- Geo-targeting unavailable for a market — coverage on bandwidth-based products is narrower. Verify availability before building on it.
- 407 Proxy Authentication Required — credentials wrong or your whitelisted IP changed.
- Success rate lower than on the standard residential pool — smaller pools mean more address reuse, which some targets notice. Reduce per-target request rate and widen your domain spread.
- Intermittent timeouts under high concurrency — you may be exceeding a connection limit the provider does enforce. Check the policy and back off slightly.
- Costs higher than per-GB despite the volume — you sized the tier wrong or your utilisation is low. Recalculate with measured throughput, not the headline capacity.
Debugging order is always: curl first, then your tool, then your code.
Evaluating a Provider
Criteria that predict real-world performance on a bandwidth-based plan:
- Actual throughput delivered against what's advertised, measured yourself during a trial
- Pool size on the unlimited product specifically, not the provider's flagship figure
- Gateway locations, and their distance from your targets
- Geographic targeting coverage on this product, verified for your specific markets
- Concurrency policy — genuinely unlimited, or capped somewhere
- Available throughput tiers and the granularity between them, which determines how badly you'll over-buy
- Upgrade and downgrade terms mid-cycle
- Minimum contract length, which is often longer on this product
- Whether the pool is shared with the per-GB product or separate infrastructure
- Protocol support — HTTP(S) and SOCKS5
- Trial terms, and specifically whether the trial lets you measure sustained throughput rather than just connectivity
Test with a real sustained load, not a single request. A plan that connects fine and delivers a third of its advertised throughput under parallel load is a plan you'll regret.
The First Thirty Days
Bandwidth-based plans have a specific onboarding risk: you commit to a tier, then discover your client can only use a third of it. A deliberate sequence avoids that.
Week one — measurement.
- Verify connectivity, classification, and geo-targeting on a trial or the smallest tier
- Measure achievable throughput under increasing parallelism and find where it plateaus
- Confirm the plateau is the purchased ceiling and not a client-side limit
- Check your library's default connection pool caps and remove them
- Verify the specific geographies you need are actually available on this product
- Record baseline success rate against your real targets
Week two — saturation.
- Raise concurrency until throughput plateaus, then measure utilisation as a percentage of tier
- Remove serial bottlenecks: move parsing, deduplication, and writes out of the request path
- Enable keep-alive and connection reuse everywhere
- Set per-domain concurrency caps so aggregate saturation doesn't come at any single site's expense
- Re-measure utilisation and confirm it's climbing
Week three — instrumentation.
- Log bytes, status code, latency, and target for every request
- Build a live view of aggregate throughput against purchased capacity
- Alert on utilisation dropping below a threshold, since that means money leaking
- Alert on success rate drops, since failed requests consume paid capacity
Week four — right-sizing.
- Compare measured monthly consumption against the per-GB alternative using real numbers
- Decide whether your tier is too large, too small, or correct
- If utilisation is stuck below 40%, fix the client before buying more capacity
- Adjust the tier before the next billing cycle
A Note on Testing Providers Honestly
Generic proxy tests predict nothing here, and connectivity tests predict even less than usual. A bandwidth-based plan can connect flawlessly and deliver a third of its advertised throughput under real parallel load.
The test that actually matters:
- Take a representative sample of the URLs you intend to fetch, at least a few thousand
- Run them through the trial with your real client configuration and real concurrency
- Measure sustained aggregate throughput over at least fifteen minutes, not a single transfer
- Record the full status code distribution alongside it
- Repeat at different times of day, since gateway congestion varies
- Compare the measured throughput against what you were sold
Then run the same test against unmetered datacenter bandwidth on the same targets. If datacenter achieves a comparable success rate, the residential premium is buying you nothing and the decision is already made.
Keep the harness. Throughput measurement should be something you can re-run whenever you change a client setting, upgrade a tier, or suspect the network has degraded.
Legal and Ethical Considerations
- Bandwidth-based residential proxies are ordinary infrastructure; legality depends entirely on use
- The sourcing question that applies to all residential networks applies here. Ask how the pool was assembled and whether node operators gave informed consent
- Scale amplifies impact. A workload capable of moving terabytes can degrade a target site without anyone intending it. Per-domain rate limiting isn't just self-protection, it's basic conduct
- Data protection law applies to what you collect regardless of routing or volume
- Public data collection and authentication circumvention remain legally distinct categories
- Large-scale collection attracts more scrutiny than small-scale collection, which is worth factoring into how you document and justify your work
Not legal advice, and jurisdictions differ. Have a lawyer review commercial operations at this scale — and at terabyte volumes, you're at a scale where that's genuinely warranted.
Unlimited Residential Compared to Every Other Option
Positioning honestly against the alternatives:
Versus per-GB rotating residential. The same classification advantage with a different meter. Per-GB wins on IP diversity, geographic granularity, and cost for modest or spiky volumes. Unlimited wins decisively above a few terabytes of continuous traffic. Many operations run both, using the bandwidth plan for bulk ingestion and the per-GB pool for targeted work needing precise geography.
Versus unmetered datacenter bandwidth. The direct competitor on cost, and dramatically cheaper. Datacenter bandwidth is also effectively unmetered, at a small fraction of the price. The only thing you lose is residential classification. If your targets don't check, datacenter unmetered is strictly better and buying residential throughput instead is the single most expensive mistake in this category.
Versus ISP proxies. ISP gives you residential classification with unmetered datacenter bandwidth on static addresses, which sounds like it covers the same ground. The difference is diversity: ISP pools are tiny, so heavy volume concentrates on very few addresses and stops looking residential in behaviour even if it still looks residential in classification. Use ISP for persistent identities, unlimited residential for volume.
Versus a managed scraping API. An API sells results and absorbs rotation, retries, and unblocking, priced per successful request. At terabyte scale, per-request pricing usually becomes uncompetitive against raw bandwidth — but it also removes an entire engineering function. Worth modelling both if your data needs are standard.
Versus building your own residential network. Not realistically available. Assembling a consensual residential network requires an app with real users, a compensation mechanism, and ongoing consent management. This is why the product is bought rather than built.
Use Cases in Depth
AI and machine learning corpus construction. The archetypal workload. Training and fine-tuning datasets require enormous volumes of raw content, collected continuously, from sources that increasingly block datacenter traffic. Raw HTML is bulky, deduplication happens after collection rather than before, and the whole pipeline runs for weeks. Per-gigabyte billing makes this financially painful in a way that distorts what teams attempt.
Full-catalogue price and product intelligence. Monitoring hundreds of thousands of SKUs across multiple retailers on a recurring schedule produces steady, predictable, very large traffic. It's also exactly the kind of target that blocks hosting ranges, which forces residential classification and makes the volume expensive under a meter.
Exhaustive site crawling. Archiving, competitive content analysis, or building a complete index of a large site means fetching every page rather than sampling. Page counts run into the millions and average payloads are full documents.
Headless browser automation at scale. Browsers load every asset on every page, multiplying bandwidth by an order of magnitude. This is the workload where per-GB billing hurts most and where unmetered throughput changes the calculus completely — and letting the browser load fully produces a more realistic traffic profile, which often improves success rate as a side effect.
Media and document collection. Images, PDFs, video, and large files are punishing under per-gigabyte billing because you're charged for payload size rather than collection difficulty.
Continuous market and content monitoring. Any workload that runs indefinitely rather than in campaigns. Steady load is precisely what throughput pricing rewards, and the flat monthly figure is far easier to budget than a consumption line that varies with ambition.
Multi-region data collection at volume. Collecting the same dataset from several countries multiplies your traffic by the number of markets. What was affordable for one country under per-GB billing frequently isn't for eight.
Architecture Patterns That Work
Decouple fetching from processing. Put a queue between them. If parsing, deduplication, or database writes run inside the request path, they become your throughput ceiling and no amount of purchased bandwidth helps. Fetch to raw storage, process asynchronously.
Store raw, parse later. Bandwidth is free now, but re-crawling to fix a parser bug still costs days. Keep the original responses. Disk is cheaper than either time or reputation.
A throughput budget per target. Aggregate saturation and per-site politeness aren't in conflict. Assign each domain a request-rate ceiling and run many domains concurrently. This keeps you considerate while keeping the pipe full.
Continuous scheduling rather than batch windows. Spreading a job across the full day uses capacity you've already bought. Compressing it into a two-hour window means paying for twenty-two idle hours and hitting targets harder than necessary.
Utilisation monitoring as a first-class metric. Instrument aggregate bytes per second and compare against your purchased tier continuously. Utilisation is the single number that tells you whether the purchase is paying off, and most teams never measure it.
Success rate monitoring alongside it. Failed requests consume throughput you've paid for and produce nothing. With the byte meter switched off, success rate becomes the dominant efficiency metric — it's what converts purchased capacity into usable data.
Backpressure and circuit breakers. A pipeline capable of terabyte throughput can overwhelm your own storage, your database, or a target site. Build in the ability to slow down, and per-target breakers that stop when failure rates spike.
Graceful resumption. Crawls at this scale run for days. Checkpoint progress, make requests idempotent, and assume the process will be interrupted.
Frequently Asked Questions
Is it really unlimited?
Unlimited in data, limited in rate. You can move as much as your purchased throughput allows over a month, which is a very large number but not an infinite one.
How do I know which throughput tier to buy?
Measure your current consumption, convert to required Mbps at 40–50% realistic utilisation, and buy the tier above that figure. Sizing from headline capacity rather than realistic utilisation is the standard mistake.
Why is the IP pool smaller than the per-GB product?
Different infrastructure optimised for sustained throughput rather than maximum diversity. It's a deliberate trade, not a deficiency.
Can I use it for a small project?
You can, and you shouldn't. The floor price makes it poor value below roughly a terabyte a month.
Does unlimited mean I can ignore efficiency?
For bandwidth, largely yes — that's the point. For success rate, absolutely not. Failed requests still consume throughput you've paid for, so improving success rate directly increases usable output.
Can I switch between per-GB and unlimited?
Usually, though contract terms vary. Many operations run both: unlimited for the continuous bulk workload, per-GB for targeted work needing geographic precision the bandwidth product doesn't cover.
Why is my throughput lower than advertised?
Almost always client-side configuration — connection pool limits, insufficient concurrency, no keep-alive, or a synchronous bottleneck downstream of the fetch.
Is this better than unmetered datacenter bandwidth?
Only if you need residential classification. Datacenter unmetered bandwidth costs a fraction as much. Test datacenter against your target before considering this product.
Where to Get Unlimited Residential Proxies
If your workload has genuinely outgrown per-gigabyte billing, ProxyScrape's unlimited residential plans price by sustained throughput rather than data consumed, with unlimited concurrent connections and country, city, and ASN targeting on a rotating pool built for continuous ingestion. Before committing to a throughput tier, it's worth running the break-even calculation against their standard per-GB residential plans with your measured consumption — and if your targets turn out not to require residential classification at all, their unmetered datacenter bandwidth does the same job for a fraction of the price.
→ Compare unlimited residential throughput tiers against your measured usage
Bandwidth-based pricing is one of the few places in this industry where the right purchase genuinely changes what you can build, because it removes a constraint that quietly shapes every engineering decision underneath it. But it only pays off if you actually fill the pipe. The operations that get real value from these plans are the ones that raised concurrency, removed their client's default connection limits, decoupled fetching from processing, and then stopped thinking about bytes altogether — which is exactly what they paid for.