How many requests per minute can one mobile proxy IP actually handle?

Someone asked me last week why their scraper, which "worked fine on residential," started tripping captchas within 20 minutes of switching to a mobile pool. They assumed mobile IPs could absorb more traffic because the reputation is better. Half right. The reputation is better. The absorption ceiling is lower than people think, and it's set by three different parties who don't talk to each other.

So: how many requests per minute can a single mobile IP really take? Short answer, from the jobs I've run against Google, Amazon, Instagram's public endpoints, a few sneaker sites and generic Cloudflare-fronted stores: 40–120 requests/minute is the honest working range for a sticky mobile IP against a hostile target, and 8–20 RPM is where you want to sit if the target has a serious anti-bot stack. Everything above that is you borrowing against your success rate.

Why that spread is so wide is the interesting part.

Three ceilings, not one

When you fire a request through a mobile proxy, three different systems can decide you're done:

1. The target site. Rate limits, WAF (Cloudflare, Akamai, PerimeterX), or application-layer scoring. This is the ceiling people think about.
2. The carrier's CGNAT box. A real phone on Verizon or Jio shares that public IP with thousands of other subscribers. The NAT device has a per-source connection and PPS budget. Hammer it and everyone behind that IP gets degraded, which is how carriers notice proxy traffic exists.
3. Your proxy provider's own limiter. Most mobile pools (ours included) cap concurrent connections and sometimes RPS per session, because a single abusive customer burns the whole IP for every other customer rotating onto it next.

Your effective ceiling is min(target, carrier, provider). Scrapers blow up because they tune for ceiling #1 and ignore the other two.

What the numbers actually look like

A few concrete data points from recent work (same proxy pool, same scraper, different targets, 10-minute windows, sticky session):

• Public PokeAPI-style JSON endpoint, no WAF: 300+ RPM sustained, zero errors. You're bound by the carrier's RTT (90–220 ms on 4G, 30–80 ms on 5G), not by anti-bot.
• A regional e-commerce catalog behind Cloudflare on default settings: ~90 RPM for the first 15 minutes, then a slow slide into cf_chl_opt interstitials around minute 20. Backing off to 45 RPM held clean for the full hour.
• Google SERP, desktop UA, no login: 10–15 RPM is the room. Push to 25 and you'll start getting the "unusual traffic" page within the hour. Rotate the IP, start over.
• Instagram's unauthenticated web graph: 6–8 RPM, and even that is twitchy. Mobile IP helps a lot vs residential here, but the per-IP budget is tiny.

Pattern: the harder the target, the less the "mobile" label buys you in raw RPM. What it buys you is a higher pre-ban budget per IP (you get to make more total requests before the IP goes cold) and a softer failure mode — captcha instead of a hard 403, often.

What actually trips the limiter

In my logs, the signal that gets you flagged is almost never the request rate on its own. It's:

• Burstiness. 60 requests in the first 5 seconds of a minute is not the same as 60 evenly spaced. Carriers and WAFs both look at short-window PPS.
• Identical timing. time.sleep(0.5) between every request is a tell. Jitter it — random.uniform(0.3, 1.4) is a cheap, effective fix.
• Session mismatch. You rotated the IP but kept the same cookies and TLS fingerprint. The IP looks mobile, the client looks like python-requests/2.31. Discussed more in why curl works and your scraper doesn't — same root cause.
• ASN/UA mismatch. Mobile IP on AS21928 (T-Mobile US) sending a Chrome/120 Windows NT 10.0 UA with no sec-ch-ua-mobile: ?1 header. Looks like a desktop pretending to be on a phone, because it is.

The 429 you see is often the last signal in a chain the WAF already decided on.

A rule of thumb that holds up

For a target you don't know yet, I start at 30 RPM with ±40% jitter, a sticky session, and a matching mobile Chrome fingerprint, and I watch the error rate for 15 minutes. If the 2xx rate stays >98%, I step up by 15 RPM. If I see any 429s or challenge pages, I halve the rate, let the IP cool for 10 minutes, and move on. That's it. No magic.

If you need throughput beyond what one IP will carry — and you usually do — the answer is more IPs in parallel, not more RPM per IP. A pool of 20 sticky mobile sessions at 30 RPM each gives you 600 RPM aggregate with a much flatter risk profile than one IP at 200 RPM. You can grab a pool and spin per-session endpoints from the mobile proxy pool; the connect page has the auth syntax for curl/Python/Playwright.

Common questions

Does 5G let me push more RPM than 4G? A little. Lower RTT means more requests fit in a given wall-clock minute, but the carrier NAT and the target's limits don't care about your radio. Expect ~20–30% more throughput, not 10x.

Does rotating per-request get me around the limit? Against raw rate limits, yes. Against modern bot scoring, no — fingerprint and behavior carry across IPs, and a scraper that changes IP every request is itself a flag. Sticky-for-a-task + rotate-on-flag is almost always better. See sticky vs rotating.

What's the single biggest win if I'm getting throttled? Jitter + matching the user-agent to the IP class. Both are free. Rate reduction is a distant third.