It is the question that comes up before almost every proxy purchase: how many IPs do I need? It sounds like the kind of thing that should have a number for an answer, and it feels like the number that determines whether the job will work. In practice it is usually the wrong question, and teams that lead with it often buy the wrong thing. What actually decides whether your scraping runs cleanly is not how many addresses you own, it is how your requests are distributed across the ones you use, and whether any single target ever sees enough traffic from one address to care.
Here is how to think about it properly, including the one case where counting IPs really is the right approach.
Why the question is framed wrong
The instinct to count IPs is a leftover from an older pricing model. When proxies were sold per port or per static address, you bought a specific number of IPs and that number was your capacity, so counting made sense. Modern residential networks do not work that way. You draw from a large shared pool, you are billed for the bandwidth you move rather than the addresses you touch, and the number of distinct IPs you end up using is an outcome of how you configure rotation, not a quantity you purchase up front. That shift, covered in more depth in the piece on why the per-port era is over, is why “how many IPs” no longer maps onto anything you actually buy.
There is a second reason the framing misleads. A target site does not see your pool. It sees the requests arriving at its own front door, and it forms an opinion per address based on how those requests behave. Ten thousand IPs will not save a job that sends its entire volume through a handful of them, and a modest number of well-distributed addresses will comfortably run a job that a naive setup could not. Distribution is the variable, not inventory.
What actually determines your requirements
Four things decide what a job needs. Work through them in order and the answer falls out.
The first is your request rate per target. Not your total request volume across everything, but how many requests you send to any one site in a given window, because rate limits are enforced per IP per target. The second is concurrency, meaning how many requests you have in flight at once, which sets how many addresses are in simultaneous use. The third is session requirements: whether your work needs a held IP for a multi-step flow, which is the one case that turns into a real count. The fourth is geographic spread, because a job covering many markets needs its volume spread across each of those markets rather than a large pool concentrated somewhere else, and where city-level targeting is involved the relevant question is availability in that city, not the size of the network overall.
The rough math for rotating work
For ordinary rotating collection, the useful calculation is not “how many IPs exist” but “how many distinct addresses does my volume need in order to stay polite at each target.”
Take your request rate to a single site, then divide by the rate you are willing to send from any one address. If a job sends 60,000 requests an hour to one target, and you want no address sending more than roughly one request every 20 seconds to that target, which is 180 an hour, then that volume needs to be spread across something on the order of 330 distinct addresses at any given time. Change either input and the answer moves: halve the volume and you need half as many, slow each address down and you need more. The numbers here are illustrative, since every target tolerates a different rate and you should tune to what a specific site actually accepts, but the shape of the calculation is the point. You are solving for distribution, and the pool simply has to be large enough and well-distributed enough in your target markets to supply it.
This is exactly what load balancing does for you, and why unlimited concurrent connections matter more than a headline IP count: the constraint that bites is how many requests one address sends to one site, not how many addresses exist in total. If you are hitting many different targets, the math applies per target, and volume spread across fifty sites is far less demanding than the same volume aimed at one.
The case where you really do count: sticky sessions
There is one situation where a number is genuinely the right answer, and it is worth being precise about it. When your work needs a held identity, a multi-step search, a login flow, a checkout-style sequence, or any process where a site tracks state across requests, each of those concurrent flows needs its own sticky session on its own IP for as long as the flow lasts. Here the count is direct: fifty simultaneous sessions means fifty held addresses at that moment, and five hundred means five hundred.
So the honest version of the question is not “how many IPs do I need” but “how many concurrent sticky sessions do I need,” which is a question about your workload’s shape rather than about the network. Everything that does not require a held identity should rotate, because rotation spreads load automatically and is how the rotation model is designed to be used.
Why raw pool size is a weak comparison metric
Providers advertise pool sizes, and the numbers are large enough to be difficult to compare meaningfully. Three things matter more than the headline figure.
Distribution in your markets comes first. A very large pool that is thin in the country or city you actually need is worse for your job than a smaller network that is dense there, so the only pool size that matters is the one available where you are collecting. Quality comes second, since addresses that are flagged or overused draw challenges and distorted responses regardless of how many of them there are, which is why IP reputation affects your success rate more directly than volume does, and why it helps to understand what a residential IP actually is. Concurrent availability comes third: what is usable at the moment you send traffic matters, not a cumulative count of every address the network has ever seen.
The practical consequence is that you should not choose a provider by pool size. Run your own workload against a small purchase and measure it, which is what the guide to testing speed, success rate, and location accuracy is for.
What to size instead: bandwidth
Since you are billed for data moved rather than addresses used, the number worth forecasting is bandwidth. Estimate the page or response size for your targets, multiply by the volume you plan to collect, and you have a figure that maps to what you will actually pay, which is the approach laid out in estimating monthly bandwidth. That also makes the biggest cost lever obvious, and it is not the number of IPs: fetching only what you need rather than whole rendered pages is where the savings are, as covered in cutting proxy bandwidth costs.
Configuring it
Both modes come from the same gateway, and the difference is one field in the username. Omit a session identifier and each request rotates, which is what most collection should do:
import requests
# Rotating: every request exits through a different addressROTATING = "http://customer-USERNAME-country-us:PASSWORD@p.shifter.io:443"r = requests.get("https://example.com/page", proxies={"http": ROTATING, "https": ROTATING}, timeout=15)
# Sticky: one held IP per concurrent flow, counted per sessiondef sticky(session_id): url = (f"http://customer-USERNAME-country-us-sid-{session_id}:" f"PASSWORD@p.shifter.io:443") return {"http": url, "https": url}
# 50 concurrent flows means 50 distinct session identifiersfor i in range(50): proxies = sticky(f"flow{i}") # run one multi-step sequence on this held addressRotate by default, hold a session only where a flow genuinely needs one, and let the pool handle distribution rather than trying to manage a fixed list of addresses yourself.
Validating the answer
Whatever number you arrive at is a starting hypothesis, and the only reliable confirmation is measurement. Watch success rate per target and per region, because a decline is the signal that your per-address rate is too aggressive for that site well before it becomes a data gap, which is what monitoring the pipeline gives you. When a route degrades, failover keeps the job running while you adjust. And if you are seeing blocks, the fix is more often pacing and request hygiene than more addresses, which is the substance of avoiding blocks.
A short checklist
- How many requests per hour to your single busiest target? That, divided by the per-address rate that target tolerates, is roughly how much distribution you need.
- How many concurrent flows need a held identity? That is your sticky session count, and it is the one number worth stating.
- Which countries and cities do you need, and is the pool dense in those places rather than merely large overall?
- How much data will you move? That is the number that determines cost.
- Have you measured success rate on your own workload rather than trusting a headline figure?
The bottom line
“How many IPs do I need” is a question inherited from a pricing model that no longer applies. On a modern bandwidth-priced residential network you are not buying a count of addresses, you are buying access to a pool and paying for the data you move through it, so the thing to design for is distribution: enough spread that no single target ever sees more than ordinary traffic from any one address. Rotate for volume, count only your concurrent sticky sessions, judge a network by its density in the markets you actually collect from and by the success rate it delivers on your own workload, and size your budget in bandwidth rather than addresses. Get the distribution right and the IP count stops being something you have to think about.
That is what residential proxies are built to provide, a large pool of real, home-grade IPs with country and city targeting, rotation by default, and sticky sessions for the flows that need them. The per-GB pricing is the number worth planning around, because you pay for the data you actually pull rather than for a quantity of addresses you hope is enough.