Distinct Exit IPs per Mobile Line: Pool Depth for Scrapers

If you are sizing a scraping job on mobile proxies, the number you need is not the size of the carrier's address space. It is how many distinct exit addresses one line will hand your workers over the run, how often an address comes back, and how many requests each address can absorb on the target before it draws attention. This page works through those three numbers from an engineer's point of view: what a single line yields, how a pipeline should treat repeats, when to spread a job across lines and metros, and how to write a capacity estimate that survives contact with a real carrier pool rather than a marketing page.

What one line actually exposes

Each WeProx proxy is one modem with one physical SIM, dedicated to you, sitting in a rack in one of eight US metros. The public address it exits from is assigned by the carrier gateway serving that metro, out of the block that gateway holds for that APN. Rotate and the modem drops its data session and re-attaches; the gateway assigns an address again, usually a different one, sometimes the same. That block is the whole universe of exits your line will ever see. A T-Mobile line in Chicago will never exit from a Los Angeles address or a Verizon address, however you configure your scheduler.

The size of that block is not published by any carrier and it is not fixed. It shifts as phones attach and detach, and it differs between carriers and between metros on the same carrier. As a rule of thumb, a line you rotate many times a day turns up a few hundred distinct exits in a week and low thousands over a quarter. Discovery is fastest in the first day or two and then slows, because the line has seen most of what its gateway routinely hands out. It does not reach zero.

Distinct exits depend on cadence, so compare yield

The count you observe is a function of how often you rotate, which makes raw totals a poor comparison. Rotate a line every two minutes and you will log far more distinct addresses in a day than the same line rotated hourly, on exactly the same pool. The number that transfers between lines is yield: distinct fresh addresses divided by rotations. A line yielding one new address per rotation for the first hundred rotations and then one per three is a deep block. A line that gives you eight addresses in fifty rotations is a shallow block, and rotating it harder just spins the same eight faster.

There is a second axis that yield does not capture: short-term freshness, meaning how often a rotation lands on an address the line held in the last day. Two lines can have similar long-run depth and very different repeat behaviour, because one gateway hands addresses back to the same SIM readily and another spreads them around. In our racks Verizon lines tend to yield fresh addresses readily, AT&T lines tend to be stickier and revisit addresses more often, and T-Mobile varies a lot by metro. Ask support which line in a given city is rotating freshest right now before you build a job around one.

How a pipeline should treat repeats

Repeats are not an error condition; they are the normal output of a finite pool. Design for them in your own code. The pattern that works is to treat the exit address, not the rotation event, as the unit of accounting. After each rotation, read the new public address before dispatching work. Keep a per-line memory of addresses seen recently, keyed by address, with the timestamp of last use and the number of requests already sent through it. Then decide based on that record, not on whether a rotation happened.

The last point matters more than the others. Once you keep that table, sizing stops being guesswork. You can read off how many addresses the line produced yesterday, how many were repeats, and what your effective budget per hour was.

• Dedupe by address: a rotation that returns a known address does not reset that address's request counter
• Give every address a request budget for the target and stop routing to it once the budget is spent, fresh or not
• On a repeat, rotate again after a short pause rather than instantly; a few seconds offline is often not enough for another phone to take the address on a quiet pool
• Bound the retries per worker, and after a few consecutive repeats keep working with the address you have rather than burning rotations
• Log address, first seen, last seen and requests sent; that table is your real pool depth and it tells you when to add a second line

Size by requests per address, not by pool

The headline pool figure is irrelevant to capacity. What bounds a scraping job is how many requests a target will tolerate from one address in one window before it starts serving challenges, degraded pages or blocks, multiplied by how many usable addresses you get in that window. Both factors are target specific and you find them by testing gently on the real site, not by reading a proxy homepage.

Work it backwards. Decide the requests per address per hour you are comfortable sending to the target. Take the distinct addresses per hour one line gives you at a sensible cadence, from your own table. Multiply, and that is the throughput of one line on that target. If the job needs more, you need more lines, not more rotations, because rotations past the point of diminishing yield only add repeats. Remember too that a mobile address is a carrier grade NAT address shared with many ordinary phones; targets know this and tend to be cautious about blocking a whole carrier address, but they will still notice a single address behaving like a crawler.

Spreading a job across lines and metros

When one line is not enough, the second line should usually be on a different carrier or in a different metro, not a duplicate of the first. Two lines on the same carrier in the same city draw from the same gateway block and their address sets overlap heavily; your two request counters end up double-counting the same exits. A Verizon line and an AT&T line in Houston draw from separate blocks with no overlap at all. Add a third in Miami or Phoenix and you have three disjoint pools feeding one dedupe table.

Metro choice also affects what the target sees. Carrier addresses geolocate to the carrier's gateway, not to the rack, so most of our lines read as the city they sit in, while our Boston AT&T addresses geolocate as New York and our Boston Verizon addresses as Boston. If your target keys anything on region, know which gateway you are exiting through. Moving a proxy between our metros is free, so it costs nothing to try a different gateway for a day and compare yield.

Sticky sessions have a place in scraping too

Not every job wants churn. Anything that involves logging in, paging through results or holding a cart needs the same exit for the whole flow, and a rotation mid-session is a bug, not a feature. Our lines hold an address as long as you like, carrier permitting; the ceiling is how long the carrier lets an active data session keep an address, which is often days. Rotation is always your own timer; nothing on our side moves your address on a schedule. Many scraping setups run a small mix: a sticky line for session-bound flows and one or two fresh-yielding lines for the bulk fetch. Both work over HTTP(S) and SOCKS5, and the data on every plan is unlimited, so the fetch volume is bounded by the target, not by us.

Next steps on WeProx

Do not size from this page. Buy one day on a line in the metro you care about, run your fetch at a modest cadence against the real target, and keep the address table. By the end of the day you will know the yield, the repeat rate and the per-address budget the target tolerates, and you can multiply from there. If the yield is thin, open the live chat and tell us the carrier and city; we can say which line in that metro is rotating freshest today, switch you to another carrier, or move the modem to another of our eight metros at no charge. We own and run the hardware, so that is minutes, not a ticket.

Frequently asked