How Many Proxies Do You Actually Need?

We sell proxies at Geonode, which makes this an article arguing that you should buy less than you were planning to. That is genuinely our position: an oversized pool does not make you safer, and on traffic-based pricing it does not even cost more — which means people carry the wrong mental model without ever seeing the bill that would correct it. The number that matters is concurrency against a single target, and it is measurable in an afternoon. If you take one thing from this, make it the measurement in the next section rather than any figure we could give you.

The Only Method That Works

Three steps, all empirical.

Step one: find the per-address ceiling. Run your actual workload from a single address, gradually increasing the request rate, and find where the target starts pushing back — 429s, challenges, slower responses, or degraded content. That threshold is your per-address capacity for that target, and it is the only number in this calculation that is not a guess.

Step two: state your required throughput. How many requests, over how long. Be honest about the "over how long" part, because it does more work in this equation than anything else.

Step three: divide. Required throughput divided by per-address capacity gives concurrent addresses needed. Add a margin for retries and variability — 50% is generous, and if you need more than that your measurement in step one was probably optimistic.

That is the whole method. The reason it is not the standard advice is that it requires running a test before buying, and vendors have no incentive to suggest it.

A note on step one: measure completed useful responses per second, not requests attempted. A pool returning 200s with stripped content is not working, and an aggregate success-rate metric will report it as healthy. Check for a known-stable marker in the response and count only responses that contain it.

Running the Measurement Properly

The whole method rests on step one, so it is worth being specific about how to do it without misleading yourself.

Test against your real target, not a test endpoint. A run against a service that echoes your IP address tells you your proxy works and nothing about how the site you care about will treat you. Every target has its own tolerance, and the number you need is target-specific.

Ramp gradually and record everything. Start well below what you expect to be the limit and step up, holding each rate long enough to see a pattern — a few minutes at least. Record the rate, the status codes, the response sizes and the wall-clock time for each step:

for rate in 0.2 0.5 1 2 5 10; do
  echo "=== $rate req/s"
  for i in $(seq 1 60); do
    code=$(curl -s -x "$PROXY" -o /tmp/body -w '%{response_code}' "$URL")
    size=$(stat -c%s /tmp/body 2>/dev/null || stat -f%z /tmp/body)
    echo "$rate $code $size"
    sleep "$(echo "1/$rate" | bc -l)"
  done
done | tee ramp.log

Watch response size as closely as status code. The most common form of pushback is not a 429; it is a 200 carrying a smaller page. A drop in average response size at a particular rate is the target starting to serve you something reduced, and it is invisible if you only count status codes.

Run it at different times of day. Tolerance is frequently lower during a site's peak hours, and a limit measured at 3 a.m. will not hold at midday. Take the pessimistic figure.

Repeat with a second address. If one address hits a wall at two requests per second and a second address hits the same wall at the same time, the limit is not per-address — it is on your subnet, your request shape, or something else that more addresses will not fix. That is an important negative result and it costs one extra run to obtain.

Then stop before the ceiling, not at it. Operating at the maximum rate a target tolerates means every ordinary fluctuation pushes you over it. Sizing from 60–70% of the measured ceiling gives you a job that completes reliably rather than one that completes when conditions are good.

Worked Example: Daily Price Monitoring

The most common workload, and the one where the answer surprises people most.

Requirement: 50,000 product pages checked once daily.

Measured ceiling: the target tolerates roughly one request every two seconds from a single address before rate limiting — call it 1,800 requests per hour.

Spread over 24 hours: 50,000 ÷ 24 ≈ 2,100 requests per hour.

Addresses needed: 2,100 ÷ 1,800 ≈ 1.2. Round up and add margin: two to four addresses.

Two addresses. For fifty thousand pages a day, against a pool marketed in the millions.

Now change one assumption. Suppose the job must finish within a two-hour window rather than spreading across the day:

Requirement: 50,000 pages in 2 hours = 25,000 per hour. Addresses needed: 25,000 ÷ 1,800 ≈ 14, plus margin: about 20.

Same volume, same target, ten times the addresses — because of a scheduling decision, not a scraping requirement.

That is the single most useful insight in this article. The window you allow yourself is the dominant variable. Before buying more addresses, ask whether the job actually needs to finish quickly, and how much that speed is worth. It is frequently worth nothing at all, because the data is consumed the following morning.

Worked Example: Geographic Checks

A completely different shape, and the arithmetic goes the other way.

Requirement: check regional pricing and availability across 30 markets, four times a day, on 50 pages per market.

Volume: 30 × 4 × 50 = 6,000 requests a day. Trivial.

Addresses needed for throughput: essentially one. Six thousand requests spread over a day is a request every fourteen seconds.

Addresses needed for coverage: at least one working exit in each of 30 countries, at the moment you need it.

Here the constraint is not volume at all, it is presence. What you should be evaluating is whether the provider actually has reliable coverage in the specific markets you need, at the times you run — not how many addresses the pool contains. A pool of ten million with thin coverage in three of your markets is worse than a pool of ten thousand that covers all thirty.

This is why "how many do I need" is the wrong question for geographic work and "where can you reach, reliably, and can I test it" is the right one.

Worked Example: Session-Based Work

The case where concurrency and identity are the same thing.

Requirement: operate 10 authenticated sessions in parallel, each performing multi-step sequences.

Addresses needed: 10, and they must be sticky — one address held for the duration of each session.

Volume is irrelevant here. What matters is that each session has a coherent identity: the same address throughout, with matching locale and time zone. A session whose requests arrive from four countries is not a session, it is a pattern.

The mistake to avoid is using a per-request rotating endpoint for this, which is the default on most gateways. The requests succeed, the session state is lost, and the symptom looks like an application bug for as long as it takes someone to check the exit addresses.

Note also that ten concurrent sessions does not mean ten addresses forever — it means ten at once. A workload running 200 sessions sequentially through the day still needs only ten sticky addresses, reused.

Why More Is Not Safer

The assumption behind most oversized purchases, and it is wrong in three specific ways.

Blocking is by subnet, not by address. Sites commonly block at /24 granularity. Fifty addresses in one block behave like one address when that block is blocked, so a large pool with poor distribution is not a large pool in the way that matters. Distribution beats count, and we covered the mechanics in what is a subnet ID.

Rate is the signal, not identity. If your requests look automated by timing, headers or TLS fingerprint, spreading them across more addresses spreads the signal without removing it. You end up flagging more addresses rather than fewer.

Unused addresses go stale. In a rotating pool, an address you have not used has no relationship with the target, good or bad. Holding "spare capacity" is not a stockpile of anything.

There is one genuine reason to hold more addresses than throughput requires: churn. If a target flags addresses over time, you need replacements to rotate in. That is a real requirement, and it is sized by the observed flagging rate rather than by intuition — measure how many addresses degrade per day and hold a few days' worth.

What You Are Actually Buying

Worth stating clearly, because the answer differs by pricing model and it changes what the question even means.

On per-gigabyte pricing, which is how residential and often datacentre traffic is sold, you are not buying addresses at all. You buy data, and address count is a property of the pool rather than of your plan. Asking "how many proxies do I need" in this context is a category error — the real questions are how much traffic you will move and whether the pool has coverage where you need it. Our residential traffic starts at $0.79/GB and datacentre at $0.14/GB, checked September 2026 against our pricing page.

On per-IP pricing, which is how ISP and many datacentre products are sold, the count is literally what you pay for and this whole calculation is a budget line. Ours are $1.25/IP. Here the arithmetic above is money, and getting it right is worth the twenty minutes.

Which model suits you depends on the shape of your workload rather than the headline rate, and the two are not comparable. A workload needing many addresses briefly favours traffic pricing; one needing few addresses heavily favours per-IP. We went through the arithmetic properly in the proxy pricing guide.

Rules of Thumb, With Their Limits

If you need a starting point before measuring, these are defensible. Treat them as a first guess to be replaced, not as an answer.

Two figures worth internalising. Almost no workload needs more than a few dozen concurrent addresses, and the ones that genuinely do are either geographic (many locations, low volume each) or on a self-imposed deadline. And the number that most often needs changing is not the address count, it is the schedule.

Signs You Have the Number Wrong

Too few looks like: rising 429s, challenges appearing, success rate declining as the run progresses, jobs finishing later than planned. The fix is more concurrency or a longer window.

Too many looks like: nothing. This is why the mistake persists. An oversized pool produces no symptom on traffic pricing, so nobody discovers it. On per-IP pricing it produces an invoice, which at least prompts the question.

Two things that look like "too few" and are not:

A blocked pool. If success rate collapses across all addresses simultaneously, adding more will not help — something changed at the target, or your request shape is being identified on a non-address signal.

A slow target. If responses are slow but successful, more concurrency will help throughput up to a point and then stop. Measure completed requests per second and stop increasing when that number plateaus, which it will do sooner than expected.

The general diagnostic: increase concurrency in steps and watch completed useful responses per second. It rises, plateaus, then falls. The optimum is the plateau, and it is usually a smaller number than anyone predicts.

People Also Ask

How many proxies do I need for web scraping?

Measure rather than guess: find the request rate at which a single address starts being limited on your actual target, divide your required throughput by that, and add margin. Most workloads land in single or low double digits of concurrent addresses, not thousands.

Does using more proxies make me less likely to be blocked?

Only if the block is address-specific. If your requests are identified as automated by timing, header composition or TLS fingerprint, more addresses spreads the same signal across more of your pool rather than avoiding it. Rate and request shape matter more than count.

How many proxies for 1 million requests a day?

Depends entirely on the window. Spread across 24 hours that is about 12 requests per second, which at one request every two seconds per address means roughly 25 concurrent addresses. Compressed into two hours it is twelve times that. The schedule is the variable, not the volume.

Do I need one proxy per account?

For anything session-based, one sticky address per concurrent session — not per account. Ten accounts operated sequentially through the day need ten addresses only if all ten are active simultaneously. Note that many platforms explicitly prohibit multi-account operation, so check the terms before designing around it.

Is it better to have more IPs or better IPs?

Better, meaning well distributed across subnets and appropriate to the target. Blocking commonly happens at /24 granularity, so fifty addresses in one block behave like one. A smaller, well-spread pool outperforms a larger concentrated one.

How do I know if I have too few proxies?

Rising 429s, challenge pages appearing, and success rate declining as a run progresses. If success collapses across all addresses at once, that is a different problem — something changed at the target or your requests are being identified on a non-address signal, and more addresses will not help.

Does the number of proxies affect the price?

Under per-IP pricing, directly — the count is what you buy. Under per-gigabyte pricing, not at all, because you pay for data and address count is a property of the pool. This is why the two models cannot be compared on headline rates.

How many proxies for geo-targeting?

One reliable exit per location you need, and volume is usually irrelevant. The question to ask a provider is not how many addresses they have but whether they have dependable coverage in your specific markets, and whether you can test it before committing.

Wrapping Up

The number you need comes from one measurement and one division: find where a single address starts being rate-limited on your real target, and divide your throughput requirement by it. Everything else is refinement.

The variable that dominates the result is not volume, it is the window you allow. Fifty thousand pages a day needs a couple of addresses spread across twenty-four hours and twenty across two. Before buying capacity to go faster, check whether anything actually depends on the job finishing sooner — often nothing does, and the cheapest optimisation available is patience.

And for geographic work the question changes shape entirely. Volume is trivial, presence is everything, and the useful evaluation is whether a provider reliably covers your specific markets rather than how large the pool is. That is testable in a trial, it takes an afternoon, and it will tell you more than any figure a vendor puts on a landing page — ours included.