Real Mobile Proxy Speeds: What to Actually Expect

Mobile proxies are slow compared to datacenter proxies. Not slightly slower — an order of magnitude slower, consistently, across every provider running real handsets.

This is not a defect anyone can engineer away, and it is not a throttle applied to push you up a pricing tier. It is what happens when your traffic has to cross a cellular air interface twice, in the direction that carriers deliberately starve. Understanding exactly where the ceiling comes from tells you whether mobile is the right tool for your job, and this page ends with the case where it plainly is not.

If you are trying to work out whether a specific proxy is slow or merely mobile, the diagnostic version of this page separates the two.

The number: roughly 2-3 MB/s per device

On a healthy device with good signal, expect around 2-3 MB/s. That is the realistic working ceiling, and it holds broadly across providers because it is set by the carrier's uplink allocation rather than by anyone's software. A provider can lose throughput through bad engineering; nobody can add any.

Two clarifications before the mechanism, because both come up immediately.

It is per device, not per account. If you have several dedicated devices, each has its own ceiling and they add up. What you cannot do is get more than one device's worth of throughput out of one device by opening more connections to it.

Signal quality moves it, but not by much. A phone with poor reception or on a congested tower will do worse. A phone with excellent 5G reception does not do dramatically better, for the reason in the next section.

Your download is the phone's upload

This is the whole explanation. When a phone acts as a proxy, everything the destination sends back must be pushed up from the phone to the relay before it reaches you. Cellular networks allocate far less capacity upward than downward, so what you experience as a download speed is governed by the phone's upload speed.

The chain makes it obvious once you write it out. A request leaves your client, reaches the relay, travels down the tunnel to the phone, and goes out over the radio. The response comes back over the radio into the phone — that leg uses the downlink, which is generous, and then the phone has to send it up to the relay so the relay can send it to you. That second leg is the uplink, and it is the narrow one.

So the payload direction that matters in proxy work is the direction cellular networks are least generous with. Everything else about the phone — its processor, its Wi-Fi, its storage, the tunnel implementation — is fast enough not to matter. The radio's upward allocation is the constraint, and it was designed around a usage pattern where people mostly consume.

A mobile proxy's download speed is a cellular upload speed wearing a different label.

Why the advertised 5G figure does not apply

The headline number on a 5G plan describes downlink — content arriving at a handset for a person to consume. Proxy work inverts that. The phone is a relay, not a consumer, so the number that governs your experience is the one nobody advertises and every network allocates conservatively.

This is why buying 5G hardware for faster proxy downloads is buying the wrong axis of the same product. It is not that 5G does nothing; it genuinely improves connect latency and gives a device more headroom on a busy tower, so it degrades more gracefully under contention. What it does not do is move the throughput ceiling, because that ceiling is an allocation decision about the uplink rather than a limitation of the downlink radio.

The same reasoning explains why a 4G address and a 5G address behave alike in the ways that actually matter for proxy work. Both come from the same carrier pools, both carry the same class of reputation, and both sit behind the same narrow uplink. The generation on the label is close to irrelevant to how the proxy performs.

Latency: an extra hop plus the radio

Expect noticeably higher latency than a datacenter proxy, from two independent sources that stack. Your traffic takes an extra hop through the relay before it reaches the phone, and then it crosses a radio link where transmission is scheduled rather than continuous. Neither is an implementation flaw and neither can be optimised out.

The extra hop is straightforward: your client talks to the relay, the relay talks to the device, and that adds a round trip nobody can remove without eliminating the relay, which is impossible, because carrier NAT makes the phone unreachable from the public internet.

The radio contributes more than people expect. A cellular link does not transmit whenever it wants; it requests airtime, waits to be scheduled, and transmits in its allotted slot. That scheduling adds milliseconds per exchange, and it compounds on protocols that need many round trips. A TLS handshake through a mobile proxy costs meaningfully more than the same handshake through a datacenter host, before any data moves.

The practical effect: request-heavy workloads suffer more than byte-heavy ones. Fetching a thousand small pages through a mobile proxy is disproportionately slow relative to fetching a few large ones, because you are paying the latency tax a thousand times instead of a handful.

Slow connects to protected destinations are the destination's decision

Some CDN-protected sites take 7-8 seconds to establish a connection from a cellular address that has been idle or heavily used, while ordinary sites connect normally through the same proxy at the same moment. This is an external throttle applied at the destination, not a fault in the proxy, and it is one of the most misdiagnosed symptoms in this business.

The tell is selectivity. If throughput is fine and one class of destination is slow to connect while everything else is instant, the problem is not your bandwidth, your device or your provider — it is a decision being made about your address on the far side. Large edge networks apply additional scrutiny to cellular ranges under some conditions, and that scrutiny shows up as latency rather than as an error page.

Separate the two measurements before drawing any conclusion:

• Connect time is how long it takes to establish the connection. High connect time with normal transfer speed points at the destination.
• Transfer speed is bytes per second once the connection exists. Low transfer speed with normal connect time points at the uplink, the radio, or contention on the device.

A rotation often clears the slow-connect case, since it presents a different address. That is a workaround rather than a fix, and it is worth being clear that the underlying decision was never yours to make. Rotating repeatedly to chase it is the wrong instinct if the account behind the requests has any state worth preserving.

Concurrency does not create bandwidth

Parallel connections split one uplink; they do not add capacity. Past a modest point, they make things actively worse — all of a device's connections are multiplexed over a single tunnel, and under heavy fan-out the device's IO pool gets pinned, the multiplexer wedges, and the phone goes silent while still appearing connected.

Recovery for that condition takes about three minutes: a relay-side watchdog notices the device has stopped answering and force-closes the tunnel so it re-establishes. That is a working safety net, and it is also three minutes during which the device produced nothing. A job tuned to twenty concurrent requests that intermittently wedges will finish later than the same job tuned to five that never does.

This changes how you configure a scraper. The instinct to raise concurrency until throughput stops improving is correct on datacenter infrastructure and wrong here, because on a phone the curve does not plateau — it falls over. Start low, measure completed requests per minute rather than requests issued, and increase only while that number is genuinely rising. For Scrapy specifically this means tuning concurrency down and download delay up relative to whatever you would use with datacenter proxies.

Large uploads deserve their own mention, because they fight the same constraint from the other direction. Sending a big file out through the proxy consumes exactly the resource that is scarce, and a tunnel without proper flow control will drop the stream rather than slow it down, which surfaces as a failed upload rather than a slow one. We hit this ourselves and fixed it by coalescing writes so the stream degrades gracefully instead of dying, but the underlying scarcity is unchanged.

What to expect by workload

If throughput is the requirement, use datacenter proxies

Stated as plainly as possible: if you need raw speed and your destinations are not scrutinising your address, datacenter proxies are the correct tool and they are cheaper. They are faster by an order of magnitude, they cost a fraction as much per gigabyte, and they have none of the physical constraints on this page. Buying mobile for bandwidth is paying a large premium for the slowest option available.

Mobile earns its cost in exactly one situation: when detection is what stands between you and the work. Carrier addresses sit behind carrier-grade NAT shared by large numbers of real subscribers, which makes blocking them expensive for a platform in a way that blocking a datacenter range is not. That is the entire product. You are not buying speed, capacity, or reliability — on all three, datacenter wins outright. You are buying an address class that platforms are reluctant to block.

So the decision is a single question: is bandwidth your constraint, or is detection? If a datacenter proxy gets you the data, use one, and spend the savings on something else. If a datacenter proxy gets you a block page and a mobile address does not, the throughput ceiling is the price of entry and 2-3 MB/s is what entry costs. The middle ground — residential — trades some of both, and that comparison is worth reading before committing either way.

The honest limits

We cannot raise the uplink ceiling. It is the carrier's allocation on hardware we do not control, and no amount of tunnel engineering, protocol choice or hardware upgrade moves it. Any provider quoting datacenter-grade speeds on a mobile IP is measuring something that did not cross a radio.

We cannot remove the extra hop either, because the relay exists for a structural reason rather than a commercial one. What we can do is keep our own overhead small, avoid dropping streams under load, and recover a wedged device automatically instead of waiting for you to notice, and those are real improvements that still leave the physics exactly where they were.

The one genuinely useful thing to take from this page: measure completed work, not peak speed. A mobile proxy that sustains modest throughput reliably for six hours beats one that spikes higher and wedges twice, and the second is what aggressive concurrency buys you.

Frequently asked questions

How fast is a mobile proxy?

Roughly 2-3 MB/s per device is the realistic working ceiling. That figure is set by the cellular uplink allocation, not by the provider's software, so it is broadly consistent across services running real handsets on real carrier SIMs.

Why is my 5G mobile proxy not faster than my 4G one?

Because the bottleneck is the uplink, and 5G marketing figures describe the downlink. When a phone acts as a proxy, everything you download must be pushed up from the phone first, and that direction is deliberately narrower on every cellular generation.

Is 2-3 MB/s slow for a proxy?

Compared to a datacenter proxy, yes, by a wide margin. Compared to what a physical handset on a carrier network can push upward, it is normal. You are buying an address class that is expensive for platforms to block, and the throughput ceiling is the cost of that.

Why do some sites take 7-8 seconds to connect through a mobile proxy?

Certain CDN-protected destinations apply extra scrutiny to cellular addresses that have been idle or heavily used, which shows up as a slow connect rather than an error. It is a decision made at the destination, not a fault in the proxy, and it usually clears after a rotation.

Will more concurrent connections make my mobile proxy faster?

No. Parallel connections split the same uplink, and past a point they degrade it — under heavy fan-out a device's multiplexer can wedge and take about three minutes to be recovered by a watchdog. Modest concurrency finishes a job sooner than aggressive concurrency.

When should I use datacenter proxies instead of mobile?

Whenever throughput is the requirement and the destination is not scrutinising your address. Datacenter proxies are dramatically faster and dramatically cheaper. Mobile only pays for itself when the thing standing between you and the data is detection rather than bandwidth.