How many mobile proxies do you actually need

Most people buy too many proxies, or buy one and wonder why everything tangles. The right number is not a vibe and it is not whatever the sales page upsells you to. It comes from what you are actually doing, and once you frame it correctly the number almost falls out on its own.

I run the farm, so I would rather you buy the right amount and stay than overbuy and churn. Here is the plain math.

First, which job are you doing

There are two completely different questions hiding inside “how many do I need,” and they have different answers.

Multi-account work counts identities. Scraping work counts concurrency. If you try to size multi-account work with scraping math, or the reverse, you get the wrong number. So before anything else, decide which one you are. Most people are mostly one of them.

One thing that stays constant either way: one modem is one port is one IP line. That is the unit you are counting. If the host, port, and credential structure is still fuzzy, what is a mobile proxy covers the anatomy.

Multi-account: count believable people

The instinct is one IP per account. That is usually too many, and it is the most common overbuy I see.

The real unit is the believable person, not the login. Think about your own phone. It holds your personal accounts, a couple of work logins, a few apps you are signed into, all on one IP, and no platform blinks, because it looks like one person with a normal digital life. You can group accounts the same way. Accounts that could plausibly belong to one person can share one sticky line.

So the rule of thumb is: one sticky line per identity cluster you need to keep genuinely separate. If you are running five distinct personas that must never look related, that is five lines. If you have fifteen accounts that fold into five believable people, it is still five. The principle behind running multiple accounts without bans is consistency per identity, and a stable IP per person is what delivers that.

Scraping: count concurrency, not pages

For scraping, the number of total pages barely matters. One rotating line can carry a huge number of sequential requests over time. What you are really sizing is how many requests you need in flight at once.

The simple formula:

lines = peak concurrent requests ÷ what one line sustains within the target’s rate limit

Work out how fast you can safely hit the target from a single IP without tripping limits, work out the peak throughput you need, divide, and round up. Leave a little headroom. That is your line count. Notice total volume never enters the formula directly, it shows up only through how much concurrency you need to finish in your time window. The web scraping case studies are all concurrency-sized jobs, not page-count-sized ones.

Bandwidth is a different axis

A trap worth naming: needing more data is not the same as needing more IPs.

If your scrape pulls a lot of gigabytes but at modest concurrency, you need more bandwidth, not more lines. If you have heavy parallelism but light pages, you need more lines, not more data. They are two separate dials. Buying extra IPs to solve a bandwidth problem just leaves you paying for idle lines. Size them independently.

Two worked examples

Multi-account. You manage a handful of personas that must stay unrelated, say five. Each gets one sticky line so its IP stays consistent with that identity. Five lines, done. You do not add lines for the twenty individual accounts underneath those five people, because they share an identity and therefore share an IP believably.

Scraping. You need to pull roughly a target number of pages an hour. You test and find one IP can safely do, say, a request every few seconds before the target starts rate limiting. Divide your needed throughput by that safe per-IP rate, round up, add headroom. That is your line count, whether the total job is ten thousand pages or a million, because the constraint is concurrency against the rate limit, not the grand total.

The mistake in both directions

Too few lines and everything contends on one IP: your scrape trips rate limits, or your accounts start looking related because they share an address they should not. Too many lines and you are paying every month for IPs that sit idle.

The fix is the same for both: start lean, measure your real load, and add from actual numbers. You almost never know your true number on day one, and that is fine, because you are not supposed to guess it, you are supposed to watch it.

Right-size before you commit

The honest way to land on your number is to run a small amount on a trial, watch your real concurrency or your real identity count, and scale from there instead of buying a big plan on a guess.

There is a free trial of Singapore Mobile Proxy, real SIMs on Singtel, M1, and StarHub from my own farm. Start with one or two lines, run your actual workload, and let the real load tell you the number. It is cheaper than overbuying and a lot more accurate than a rule of thumb from a sales page.

Get new guides and videos first — join the Telegram channel.