Why Your Provider's Pool Size Number Is Close To Meaningless
The number on the pricing page
Every proxy provider puts a number on their homepage. “72 million IPs.” “10 million residential proxies.” “Access our pool of 50 million.” It sits right next to the price, formatted to look like the thing you’re actually buying. It isn’t.
Pool size tells you how many IPs a provider has ever seen pass through their network, or in some cases how many are theoretically reachable through their partner SDKs at a given moment. It does not tell you how many of those IPs are online right now, how many are usable from your target country, how many are already burned on the sites you care about, or how many will still be alive next week. Those are the numbers that determine whether your scrape runs cleanly. The headline figure is closer to a marketing input than an operational one.
I run proxy infrastructure for a living, both selling it and using it against my own scraping jobs, and I’ve spent enough time watching dashboards to know the gap between “pool size” and “usable capacity right now” is often enormous. Understanding why closes that gap for you as a buyer.
What actually goes into the number
Residential and mobile proxy networks are built on consumer devices running an SDK, usually bundled into a free app, VPN, or browser extension. Every device that has ever installed that SDK and connected once gets counted. A phone that installed the app eighteen months ago, was uninstalled a week later, and hasn’t been seen since is still sitting in that count for most providers, because removing dead entries from a “total network size” number makes the number smaller, and smaller numbers don’t sell.
Datacenter pools are counted differently but the inflation logic is similar. A provider might lease IP blocks across several data centers and report the full block size, even though a meaningful chunk of those addresses are already flagged by major CDNs and blocklists before you ever touch them.
Mobile pools get an extra layer of noise: carrier-grade NAT means thousands of real subscribers share a small number of public IPs at any moment, so what looks like “IP count” on a mobile network is really closer to “how often the carrier rotates the visible address,” not the sum of individual devices online.
None of this makes the number a lie, exactly. It’s usually a real count of something that happened at some point. It’s just not a count of what you need to know before you commit a budget.
The four numbers that actually matter
If you’re evaluating a provider, the ones worth asking about are:
Concurrent live IPs. How many exit nodes are actually online and passing traffic in the last hour, not the last year. This is the number closest to real capacity. Reputable providers with real dashboards can usually show you this, because it’s the same number their own network health monitoring depends on.
Geographic and ASN density where you need it. A 50 million IP pool that’s 90% concentrated in three countries is useless if your target market is somewhere else. Ask for a breakdown by country and, ideally, by carrier or ASN if you’re buying mobile. A provider quoting “carrier-grade IPs” without naming which carriers is a provider that hasn’t looked closely at their own supply.
Rotation behavior, not just rotation existence. Does the pool rotate on every request, on a timer, or only on manual refresh? Fast, predictable rotation from a small healthy pool is often more useful to a scraper than slow rotation from a huge stale one, because it changes how much fingerprint and rate-limit exposure accumulates per session.
Reputation of the IPs you’re actually assigned. This is the one providers almost never volunteer. An IP that’s been hammering the same handful of ecommerce sites for months carries history with those sites’ detection systems regardless of how big the provider’s total pool is. Pool size says nothing about whether the specific addresses routed to your account are fresh or already flagged.
Why size stopped correlating with quality
There was a period where a bigger pool genuinely meant more headroom, because most detection systems worked mostly off IP reputation and request volume per address. That’s not where the industry is anymore. Modern anti-bot systems, the ones used by major retail, travel, and social platforms, weight a combination of signals: TLS and HTTP fingerprint consistency, browser automation artifacts, request timing and pattern, cookie and session continuity, and IP reputation as just one input among several.
Against that stack, a provider can have ten million IPs and still get a scraper blocked in an afternoon if every request rotates IP but reuses the same TLS fingerprint, the same header order, and the same request cadence every single time. Conversely, a smaller pool paired with careful session handling, realistic pacing, and a consistent browser fingerprint per session can outperform a much bigger pool used carelessly. Pool size is one input to one part of the detection equation. Treating it as the whole story is how people end up disappointed after paying for the biggest number on the page.
This is also why “our proxies are undetectable” is a claim worth being suspicious of on sight. No provider controls the fingerprinting, timing, or session logic happening in your own scraper, and no provider can promise an outcome that depends on decisions made on both ends of the connection plus a detection system neither side can see the internals of.
What a defensible pool actually looks like
From the operator side, running a network I’d want to sell honestly, the pool metric I trust is concurrent healthy exits per target geography, checked against a live health probe, not a lifetime device count. That number is smaller than the marketing figure, sometimes by an order of magnitude, and it should be. A provider willing to show you that smaller, real number is telling you more about their operation than one who leads with the biggest lifetime count they can construct.
If a provider won’t give you concurrency figures, geographic breakdowns, or a trial period long enough to test against your actual targets, that reluctance is itself information. It usually means the operational number would look a lot less impressive than the marketing one.
What to do with this before you buy
Ask for a trial or a small paid test batch before committing to volume pricing. Run it against your actual target sites, not a generic IP checker, and watch success rate, block rate, and latency over a realistic session length rather than a single request. Ask specifically for concurrent live count in your target country, not total network size. Ask how rotation is triggered. None of this guarantees a clean run against every target, no proxy purchase can promise that, but it replaces a marketing number with data you generated yourself, against the thing you actually care about.
The pool size on the pricing page will keep growing every year because it costs a provider nothing to let it grow. Your actual scraping success depends on a much narrower slice of that number, and the only way to know that slice is to test it directly.
Looking for a straight comparison of proxy types and providers based on how they actually perform, not on pool size claims? Head back to the Proxy Scraping homepage for the rest of our guides.
Get new guides and videos first — join the Telegram channel.