The disclosure that shapes this article: we are Geonode and we sell access to proxy pools, so we have an obvious incentive to quote a large number and move on. We would rather tell you that pool size is mostly a marketing figure, that it is unverifiable from your side, and that a smaller well-distributed pool routinely outperforms a larger concentrated one. That argument cuts against our own headline numbers as much as anyone's. The tests below work on any provider, including us — run them during a trial and buy on the results rather than on the landing page.
What a Proxy Pool Is
Instead of configuring a specific proxy at a specific address, you configure one endpoint. Behind it sits a set of addresses, and the provider's gateway selects one for each request or each session.
your client → gateway.provider.com:9000 → [ one of many exit addresses ] → target
The gateway handles selection, health checking, authentication and — depending on the product — geographic targeting and session persistence. From your side there is one hostname and one set of credentials.
Three things follow from that structure, and they are the whole substance of the topic.
You do not choose the address. You express preferences — a country, a session, sometimes a city — and the gateway resolves them. Which specific address you get is not yours to decide.
You cannot audit the pool. You see the addresses you are given. Whether there are ten thousand or ten million behind the gateway is not observable from outside, which is precisely why the advertised figure is a poor basis for a decision.
Behaviour is shared. Other customers use the same addresses. Their conduct affects your success rate, and yours affects theirs.
Pool Size Is the Wrong Metric
"150 million residential IPs" is the standard headline across this industry. Here is why it should not drive your purchase.
It is unverifiable. No customer can count a pool. The figure is a claim, and claims that cannot be checked drift upward across a market over time.
It counts addresses seen at any point, not addresses available now. Residential pools are built from connections that come and go. An address observed once last quarter may still be in the total.
It says nothing about where they are. A hundred million addresses concentrated in a handful of countries is useless if you need Portugal. What matters is availability in the specific locations you need, at the times you need them.
Concentration destroys the value of raw count. Sites block by subnet, not by address — so fifty addresses inside one /24 behave, from a blocking perspective, more like one address than fifty. A pool of ten thousand addresses spread across four thousand distinct /24s is more resilient than a million concentrated in a few hundred blocks. Consecutive addresses are also the cheapest kind for a provider to acquire, which is exactly why headline counts inflate more easily than diversity does. We went into the mechanics in what is a subnet ID.
It says nothing about behaviour on your target. The only measurement that predicts your success rate is your success rate, on your target, over time.
The Four Things That Actually Determine Quality
1. Distribution. How many distinct subnets and autonomous systems the addresses span, in the countries you need. This is the single best predictor of resilience and it is measurable during a trial.
2. Availability in your locations. Not the coverage map — the actual observed success rate from the specific cities and countries your work depends on. Providers with excellent global coverage can be thin in exactly the place you need.
3. Reputation. Whether the addresses are already flagged by your targets. This is not a property of the pool in the abstract; it is a relationship between the pool and the site you care about, which is why it can only be tested against your real targets.
4. Sourcing. How the addresses were obtained. For residential pools this determines both ethics and stability. Networks assembled without informed consent from the people whose connections carry the traffic are unstable — participants leave, devices go offline, and the enforcement action Google's threat intelligence team announced in January 2026 against a group of interlinked resellers demonstrated that the legal exposure is real too. Ask the question; treat evasion as an answer.
None of these appear on a pricing page. All four are testable in a trial.
Rotation Models and When Each Is Right
How the gateway assigns addresses matters more for your success rate than how many exist.
Per-request rotation. A new address for every request. Right for stateless, high-volume collection of independent pages. Wrong for anything involving a session, because a multi-step sequence arriving from four countries is not a pattern a real user produces.
Sticky sessions. The same address held for a defined period — typically anywhere from one minute to half an hour. Right for anything with continuity: logins, multi-step flows, cart operations, paginated results tied to a session. Most providers expose this through a session identifier in the username or through a specific port.
Static addresses. The same address indefinitely, usually ISP or datacentre products priced per IP. Right when you want a stable, warm identity and are prepared to manage its reputation yourself.
Custom rotation. You hold your own list and choose. Maximum control, maximum work.
The common and expensive mistake is using per-request rotation for session-based work. It is the default on most gateways because it suits the most common use case, and it silently breaks anything stateful — the requests succeed, the session state is lost, and the symptom looks like an application bug.
How Many Addresses Do You Actually Need?
Far fewer than the marketing implies, and the right way to find out is empirical rather than theoretical.
Measure where the limit is. Run your workload from a single address and increase the rate until you start seeing 429s, challenges or degraded responses. That threshold is your per-address capacity for that target.
Divide. Your required throughput divided by per-address capacity is roughly the number of concurrent addresses you need.
A worked example. Suppose a target tolerates roughly one request every two seconds from one address before rate limiting — 1,800 requests per hour. You need 50,000 requests per day. Spread across 24 hours that is about 2,100 per hour, so two addresses would technically suffice, and four gives comfortable headroom for retries and variation.
Two addresses. Against a pool advertised in the millions.
That gap is the point. The reasons you might genuinely need more:
- Your work is geographic, and you need presence in many locations rather than volume
- You must complete a burst quickly rather than spreading it over a day
- Reputation decays and you need addresses to rotate out of
- Your target's limits are per-address and much tighter than the example
Even accounting for those, the honest number for most workloads is tens to low hundreds, not thousands. And with a traffic-priced pool the address count is not what you pay for anyway — you pay for the bytes, which is why the arithmetic that actually matters is the one in our proxy pricing guide.
How Pools Are Assembled
Worth understanding, because it explains the price differences and the ethics.
Datacentre pools are addresses allocated to hosting providers, running on servers the provider controls. Cheap, fast, stable, allocated in contiguous blocks — which is why they are also the easiest to identify and block wholesale. A site can exclude an entire hosting provider with a rule on the autonomous system number.
Residential pools route through consumer connections. The provider does not own those connections, so somebody has to be compensated: typically through applications or SDKs that pay users, or provide a free service in exchange. That per-gigabyte cost is real and does not fall away with scale, which is why residential pricing sits where it does — roughly $0.79 to $7.00 per gigabyte across the market.
ISP or static residential pools are addresses registered to consumer ISPs but hosted in datacentres. Consumer-looking, stable, priced per address rather than per gigabyte.
Mobile pools route through carrier networks, where addresses are shared among many subscribers by the carrier itself. The most expensive, and genuinely different in how they are treated.
The inference worth carrying: an unusually cheap residential pool should prompt a question rather than a purchase. The underlying cost is real. Well below market means either a volume advantage the provider can explain, or a sourcing practice that did not involve paying anyone.
Managing Your Own Pool Versus Buying One
Occasionally worth doing, more often not.
Buying gets you scale, geographic coverage, health checking, and someone else's problem when addresses go bad. You pay per gigabyte or per address and you accept that you share the pool.
Building — renting servers and running your own proxies — gets you exclusive addresses whose reputation you alone control, no per-gigabyte metering, and full visibility. What it costs is server rental, setup, monitoring, and the ongoing job of replacing addresses that get flagged. It also gets you datacentre addresses only, since you cannot legitimately assemble a residential pool yourself.
The reasonable rule: build if you need a small number of stable datacentre addresses whose reputation matters to you and your volume is high enough that metering hurts. Buy if you need geographic spread, residential characteristics, or scale you would not want to operate.
The hybrid that works well in practice is a small self-managed set of datacentre addresses for high-volume work against tolerant targets, plus a purchased residential pool for the specific requests that need it. Most workloads are mostly the former, and paying residential rates for pages that a datacentre address fetches happily is the most common way to overspend here.
Measuring a Pool Before You Commit
Do this during the trial. It takes an hour and it is worth more than any comparison table.
Count distinct addresses and distinct subnets:
for i in $(seq 1 300); do curl -s -x "$PROXY" https://api.ipify.org; echo; done \
| sort -u > ips.txt
wc -l < ips.txt # unique addresses
cut -d. -f1-3 ips.txt | sort -u | wc -l # unique /24 blocks
The ratio of blocks to addresses is your diversity signal. Close to 1:1 is excellent. Ten addresses per block is concentrated.
Repeat per country. Aggregate diversity hides local concentration, and local is what you need.
Measure success rate on your real target, segmented by target and by region, over several days rather than several minutes. Reputation problems and time-of-day effects do not show up in a five-minute test.
Check the addresses look like what you paid for. A whois on a sample should show consumer ISPs for a residential pool, not hosting companies.
Test session behaviour. Confirm sticky sessions actually hold the same address for the advertised duration, and that the address changes when you expect it to.
Test geolocation by outcome, not by lookup. Does regionally distinct content actually differ? An IP lookup reporting "Japan" while the page shows you your home content means the geolocation is not landing where it matters.
People Also Ask
What is a proxy pool?
A collection of IP addresses accessible through a single endpoint, where the provider's gateway selects an address for each request or session. You configure one hostname and one set of credentials, and express preferences such as country or session persistence rather than choosing specific addresses.
How big should a proxy pool be?
Smaller than advertised numbers suggest. Measure where rate limiting starts from a single address against your actual target, then divide your required throughput by that capacity. Most workloads need tens to low hundreds of concurrent addresses, not thousands, unless the requirement is geographic coverage rather than volume.
Does pool size matter?
Much less than distribution. Sites block by subnet, so addresses in the same /24 are correlated and can be lost together. Ten thousand addresses across four thousand blocks is more resilient than a million across a few hundred. Pool size is also unverifiable from a customer's side, which is why it inflates across the market.
What is the difference between a rotating proxy and a proxy pool?
The pool is the set of addresses; rotation is the policy for assigning them. The same pool can be offered with per-request rotation, sticky sessions of a chosen duration, or static assignment. Choosing the wrong rotation policy for your workload breaks things more often than pool size does.
How do I check the quality of a proxy pool?
Sample a few hundred exit addresses, count distinct /24 blocks, and repeat per country. Then measure success rate on your real targets, segmented by target and region, over several days. Verify sticky sessions actually hold, and confirm geolocation by whether regional content differs rather than by an IP lookup.
Are bigger proxy pools more expensive?
Not directly. Residential pricing is per gigabyte, so you pay for data rather than address count, and pool size affects the price only indirectly through the provider's costs. Per-IP products are the case where address count is literally what you buy — which is exactly why the two pricing models are not comparable on headline rates.
Can I build my own proxy pool?
Yes, for datacentre addresses: rent servers, run proxy software, manage them. You get exclusive addresses, controlled reputation and no metering, in exchange for setup and ongoing maintenance. You cannot legitimately assemble a residential pool yourself, since that requires consent from the people whose connections carry the traffic.
Why does my success rate vary across a pool?
Because the addresses are not equivalent. Some are already flagged by your target, some sit in blocks with poor reputation, some are on slow consumer connections. Shared pools also carry other customers' behaviour. Measure per target rather than in aggregate, since one collapsed target is invisible in an averaged figure.
Wrapping Up
A proxy pool is a gateway with addresses behind it, and almost everything that determines whether it works for you is invisible on the pricing page.
The headline count is the least useful number available: unverifiable, inflated by addresses that may no longer exist, and silent on where those addresses are or how they are distributed. Distribution is the figure that actually predicts resilience, because blocking happens at subnet level and concentrated pools fail in groups.
The measurements that matter take about an hour during a trial. Sample a few hundred exits and count distinct blocks, per country rather than in aggregate. Run your real workload against your real targets for a few days and watch the success rate by target. Confirm that sticky sessions hold and that geolocation changes what you actually see. Then buy on those numbers.
And before any of it, work out how many addresses you need by measuring where rate limiting starts. The answer is routinely two orders of magnitude below what the marketing implies, and knowing it changes which product you should be shopping for at all.