Most descriptions of a residential proxy pool make it sound like a warehouse: a large number of addresses sitting on a shelf, waiting to be handed out. That mental model is wrong in a way that produces real operational surprises, because a pool is not an inventory. It is a population of real household connections that join and leave continuously, and almost everything that puzzles advanced teams about pool behaviour follows from that one fact.
Here is how a pool is actually assembled, what refresh means mechanically, and the consequences you should be designing around.
How a pool gets built
The addresses in a residential pool belong to real people’s home internet connections, which means a provider cannot simply buy them the way datacenter ranges are bought. They have to be contributed.
The mainstream mechanism is participation through software. A person installs an application, or an SDK embedded in one, that offers something in return for sharing a slice of their connection: an ad-free tier, a paid feature, a small payment, access to a service. When that device is online and idle enough, it can carry a request on behalf of the network. The provider maintains relationships with the developers who embed that SDK, and those relationships determine the geographic and network shape of the pool, which is why two providers with similar headline totals can differ substantially in any given country. The ethics of that arrangement, and how to audit it, are the subject of how providers ethically source their IPs.
The consequence worth internalising: the pool’s composition is downstream of which apps are popular where. It is not evenly distributed, it is not centrally planned, and it changes as those apps gain and lose users.
What “refresh” actually means
Pools turn over constantly, for reasons that have nothing to do with the provider.
Devices go offline when people close an app, put a phone in a pocket, leave the house, or go to sleep. Home connections get new addresses when routers restart or an ISP’s lease expires, so the same household can appear as a different address tomorrow. Participants withdraw. New ones join. On top of that, providers themselves remove addresses that have degraded, whether through poor reputation or unreliable behaviour.
None of that is a maintenance window. It is the steady state, happening continuously in the background, which is why a residential pool is better modelled as a flow than a stock.
Pool size is not availability
This is the practical heart of it, and it is where headline numbers mislead.
A published pool figure is usually cumulative: addresses the network has seen over some period. What determines your experience is concurrent availability, meaning how many distinct addresses can serve you at this moment, in the country you asked for, with the filters you applied. Those two numbers differ by orders of magnitude, and only the second one constrains your job.
Three things narrow it further. Geography: a global figure says nothing about your market, which is the argument in country availability. Filters: adding a city or an ASN cuts the eligible set sharply, since only addresses matching every criterion qualify. And time: because the pool follows human activity, the same country is deeper in its local evening than at four in the morning.
The upshot is that “how big is the pool” is close to unanswerable in a useful way, while “how many distinct addresses do I actually get for my filter, at my concurrency, at the hour I run” is measurable in twenty minutes and is the number that matters.
The five behaviours churn explains
Once you model the pool as a population rather than an inventory, a set of otherwise puzzling behaviours becomes obvious.
Sticky sessions end early sometimes. You asked for a ten-minute session and it lasted four, because the underlying device went offline. A sticky session is a best effort to hold an address for a duration, not a lease on infrastructure, and code that assumes otherwise breaks intermittently. Handle it as a normal event: detect the change and restart the sequence rather than treating it as an error, per sticky versus rotating.
The same address recurs. Rotation selects independently each time rather than cycling through a list without repetition, so repeats are expected, and they become frequent when a narrow filter shrinks the eligible set. That is arithmetic rather than a fault, and it is one of the causes covered in IP not rotating.
Performance varies between addresses. These are consumer connections with their own bandwidth, congestion, and household usage, so latency has a much wider distribution than datacenter infrastructure. Percentiles are the honest way to describe it; averages hide the tail that actually affects your schedule.
Availability moves through the day. A job that succeeds at 20:00 and struggles at 04:00 in the same market is usually seeing diurnal pool depth rather than a target change.
Results differ between two runs of the same job. Different addresses, different networks, different reputations. Some variance is inherent, and treating every fluctuation as a regression wastes a lot of investigation.
Designing for a population
Practical consequences for anyone building on top of this.
Treat addresses as disposable and routes as the unit you manage. You never chose an address and cannot keep it, so health tracking belongs at the route and session level, which is the model in monitoring proxy health at scale and building a proxy manager.
Make jobs resumable and idempotent. If a session can vanish mid-sequence, the sequence needs to be restartable without duplicating work or corrupting a record.
Choose TTLs deliberately. A long TTL is a request, not a guarantee, and asking for an hour on a consumer connection sets you up for mid-flow drops. Ask for what the flow actually needs.
Measure your effective pool rather than reading a marketing figure: sample a few hundred exits under your real filter, count distinct addresses and organisations, and repeat at the hours you run. That number, not the headline, is what should inform concurrency and distribution decisions, alongside the reasoning in how many proxy IPs you actually need.
And schedule with the population in mind, since running a heavy job for a small market during its overnight hours is fighting the pool for no reason.
What good pool management looks like from outside
You cannot audit a provider’s internals, but the effects are observable. Consistent success rates across the hours you run suggest the pool is deep enough in your markets rather than merely large in aggregate. A wide spread of consumer ISP organisations in your exit sample suggests genuine residential supply rather than a diluted one, which is the check in spotting datacenter IPs sold as residential. Geolocation that matches what targets actually believe, rather than only what a lookup service reports, suggests the geographic labelling is maintained. And a provider that can describe its sourcing without discomfort is telling you something about how the pool is managed generally.
The bottom line
A residential pool is a population, not an inventory. It is assembled through participation rather than purchased, its shape follows the software people actually use, and it turns over continuously as devices go offline, addresses get reassigned, and participants come and go. That single property explains sticky sessions ending early, addresses recurring, latency varying widely, availability moving through the day, and two identical runs producing different results. Design for it: treat addresses as disposable, track health per route, make sequences resumable, choose TTLs that match the flow, and measure your effective pool under your own filters at your own hours rather than trusting a headline figure that describes something other than what constrains you.
That pool is what residential proxies sit on, spanning 195 countries with country, region, city and ASN filters, and per-GB pricing so measuring your own effective availability costs only the bandwidth the test uses.