How many proxies do you actually need?

Almost everyone starts by trying to estimate a total: how many pages, how many requests, how many million rows over the month. Then they try to translate that into a number of proxies and get stuck, because the two do not map onto each other. The amount of work you do over time barely affects how many proxies you need. What matters is how much of it happens simultaneously.

”How many proxies” is really two questions

The phrase hides two different things that people mash together:

1. How many connections do you need open at the same time? This is concurrency, and it is what you are actually buying when you size a plan.
2. How many distinct IP addresses will your traffic appear to come from? This is diversity, and it is handled by rotation, largely independent of the first number.

Confusing the two leads to both mistakes: buying far more capacity than you will ever run in parallel, or worrying about IP variety when the plan already gives you all you need. Separate them and the sizing gets simple.

Concurrency is the number you size on

Concurrency is how many requests are in flight at the exact same moment. If your scraper fires one request, waits for the answer, then fires the next, your concurrency is one — no matter how many million requests you make in a day. If you run twenty workers in parallel, your concurrency is twenty.

On our port-based plan, Budget Unlimited, this maps directly: the port count you choose (5, 15, 25, 50, or 100) is how many simultaneous connections you can hold open. Pick the number to match your peak parallelism, not your daily total. A pipeline that quietly pulls a page a second all day needs very few ports; a burst job that opens fifty connections at once needs fifty.

The pay-as-you-go products, Residential / ISP and Mobile, size differently — you pay for the data you use rather than a fixed concurrency, so there the question shifts from “how many ports” to “how many GB.” And Premium Unlimited is sized by throughput in Mbps, for when sustained speed matters more than connection count.

Rotation does the heavy lifting on IP variety

Here is the part that surprises people: a small number of ports can put your traffic behind a very large number of IPs. The port is a lane, not an address. Over time, and on demand, each lane can exit from many different residential IPs.

So if your worry is “I need thousands of different IPs so I do not get pattern-flagged,” you almost certainly do not need thousands of ports to get them. You control IP behavior through rotation and session handling: let addresses rotate for maximum spread, or pin a session when a task needs to keep the same IP across several steps. That choice — how your IPs behave over a run — is a separate dial from how many run at once, and it is covered in rotating or sticky sessions.

Matching it to a plan

Put together, the sizing looks like this:

• Steady, low-parallelism work (monitoring, periodic checks, a modest crawler): a small port count on Budget Unlimited usually covers it, with rotation giving all the IP spread you need.
• Bursty or heavily parallel work (large crawls, many workers, tight deadlines): size the port count to your peak number of concurrent workers, and add a little headroom.
• Data-heavy, quality-sensitive work where you would rather not think about concurrency at all: the pay-as-you-go products bill by GB and keep parallelism generous, so you size by volume instead.
• Sustained high-speed transfer: Premium Unlimited, sized by Mbps.

A simple way to size it

You do not need a spreadsheet. Ask three questions:

1. At my busiest moment, how many requests are open at once? That is your concurrency floor. Round it up.
2. Am I bound by parallelism or by data? If throwing more workers at it makes it finish faster, you are concurrency-bound — size on ports. If you are just moving a lot of bytes at a comfortable pace, you are data-bound — size on GB.
3. Do I need the same IP to persist across steps of a task? If yes, plan to use sessions; if no, let it rotate. Either way it does not change how many ports you buy.

Start a notch above your honest peak concurrency, watch how it runs for a few days, and adjust. Over-buying capacity you never run in parallel is the most common and most wasteful mistake.

When to add more

The signal to scale up is not “I processed a lot this month” — it is queueing. If your workers are spending time waiting for a free connection, or a burst job cannot open as many parallel requests as it wants, that is real concurrency pressure and a reason to add ports. If instead your job runs comfortably and just takes a while, more proxies will not speed it up; you are limited by pace or target-side rate limits, not by capacity.

Sized right, the number is usually smaller than people expect. Match ports to peak concurrency, let rotation handle IP variety, and choose the billing model — ports, GB, or Mbps — that fits the shape of the work. If you tell us what you are running and how parallel it gets, we will point you at the smallest plan that comfortably covers it rather than the biggest; reach us at [email protected] or through the dashboard chat.