Mobile Proxy Slow? How to Tell a Real Problem From the Physics

Here is the most useful sentence on this page, and most people who arrive here do not want to hear it: if you are getting around 2-3 MB/s through a mobile proxy, nothing is wrong.

That is the ceiling. It is not our ceiling, it is not your provider's ceiling, it is the cellular network's ceiling, and every provider running traffic through real phones lands in the same place. A customer measuring 2 MB/s on a flagship handset with full signal has a correctly working proxy.

But "nothing is wrong" is not always true, and this page exists to tell the two apart. There are real faults that look like slowness, and they have specific signatures. The first step is to stop measuring one number.

Separate throughput from connect time before anything else

Throughput is how fast bytes move once a connection exists. Connect time is how long the handshake takes before any bytes move at all. They have different causes, different fixes, and a proxy can be perfectly healthy on one while being genuinely slow on the other. Measuring them as a single "it feels slow" is why most of these tickets go in circles.

The distinction matters because the two are produced by different parties. Throughput is set by the carrier's radio link. Connect time is largely set by the destination — how much scrutiny it decides to apply before letting you in.

You can split them with one command:

curl -s -o /dev/null -x http://USER:PASS@host:PORT \
  -w "connect=%{time_connect}s  ttfb=%{time_starttransfer}s  speed=%{speed_download} B/s\n" \
  https://example.com/some-large-file

Read it like this. A high connect with normal speed is a destination problem. A normal connect with low speed is a bandwidth question, and probably the physics answer below. Both high, on one device only, points at that device's tower.

Why 2-3 MB/s is the ceiling: your download is the phone's upload

A mobile proxy works by routing your traffic through a phone's cellular connection. When you download through it, the data arrives at the phone and the phone then sends it to you — so your download is the phone's upload. Carrier uplink is far narrower than downlink, and that asymmetry is the speed you actually experience.

That is the whole explanation, and once you see it the advertised numbers stop being confusing. Carriers optimise for downlink because that is what phone users consume; uplink gets a much smaller share of the radio because ordinary handsets rarely need it.

A proxy inverts that assumption. Every byte you pull through the device has to be pushed back out over the narrow half of the link. The headline 5G figure on the box describes a pipe your traffic barely uses.

Some consequences worth internalising:

• A faster phone does not raise the ceiling. The bottleneck is the radio link and the carrier's allocation, not the handset's CPU or its modem generation.
• A stronger signal helps only up to a point. Poor signal will drag you below the ceiling; excellent signal does not lift you above it.
• No provider is exempt. Anyone selling real-device mobile proxies is subject to the same uplink. If a vendor advertises mobile proxy speeds far above this range, ask what hardware the traffic is actually leaving from.

That last point is the practically useful one. "Faster mobile proxies" is close to a contradiction. What genuinely varies between providers is stability, connect behaviour, and whether the device is shared — not peak bandwidth.

Symptom, cause, and what actually fixes it

Use this to place your symptom before you change anything. The most common mistake is applying a fleet-wide fix to a single-device fault, or trying to engineer around the uplink cap, which cannot be done.

Slow connects to protected sites are the destination's decision

Seven to eight second connect times to Cloudflare-protected destinations, from a cellular address that has been in use for a while, are an external throttle applied by the site. The proxy is not slow. The destination is deliberately taking its time deciding about you before it hands over a connection.

This shows up cleanly in the curl output above: time_connect climbs while speed_download stays exactly where it always was. Bytes move at normal speed once the connection exists. The delay is entirely in front of the transfer.

The cause is reputation scoring — the same machinery behind Cloudflare's 1015 rate limiting. An address generating steady automated-looking traffic accumulates a profile, and the site does not have to block you to make you unhappy. Adding seconds to every handshake is cheaper and just as effective.

The obvious workaround is to rotate on a timer so the address never gets old enough to be scored. We rejected that, and it is worth explaining why, because it is a tempting feature to ship.

Rotating on a schedule treats the symptom. Worse, it usually makes the underlying problem harder: a stream of short-lived addresses with no session continuity is itself a recognisable automation pattern, and sites that care respond by escalating from a slow handshake to an outright block. You would trade a measurable annoyance for an unmeasurable one. The durable fix is on the behaviour side — session continuity, plausible pacing, fewer parallel identities — which is the whole argument in dedicated vs rotating proxies.

One device slow, the rest of the fleet fine

When a single device is materially slower than its neighbours and nothing else has changed, the cause is almost always its tower gateway rather than the device or your configuration. This is a physical-location fault, and the fixes are physical.

The reasoning is elimination. Your code is the same for every device, the relay is the same, the carrier plan is the same. The variable that differs is which tower that phone attached to and how that gateway is behaving.

The two things that actually work:

Move the device. Sometimes a few metres changes the attachment. Sometimes it needs a different room or site.

Swap the SIM. A different SIM may attach differently — a cheap test even when it is not the eventual fix.

What does not work is adjusting fleet-wide settings — timeouts, concurrency limits, rotation intervals — in response to a single-device symptom. If one device is the outlier, the fault is local to it.

The same unstable-gateway fault also produces slow rotations and drifting exit addresses, so if the slow device is also taking 60-120 seconds to rotate, you have confirmed the diagnosis. That overlap is covered in the rotation diagnosis page.

The device that goes silent under heavy load

Under very high fanout — scrapers opening many parallel connections at once — a device's multiplexer can wedge. The phone stops responding rather than slowing down, and a heartbeat watchdog recovers it automatically in about three minutes. The signature is silence under load followed by an unprompted return to normal.

This is not gradual degradation, which is what makes it identifiable. A device hitting the bandwidth ceiling gets slower. A device whose multiplexer has wedged stops. If your throughput graph goes to zero rather than sagging, you are looking at this rather than at bandwidth.

Recovery is automatic, but the recurrence is worth preventing — three minutes of silence is a real cost mid-run. Reducing concurrency is the lever. Ten workers each pausing between requests still produce ten simultaneous streams through one radio, and it is the fanout that triggers this, not the request rate. Cutting the worker pool helps more than adding delays, and if you are running that much concurrency you are probably also collecting 429s at the destination.

When a slow upload is actually a failed upload

A large upload through a tunnel can fail outright rather than merely being slow, and that is a different class of bug. Bandwidth limits make transfers take longer; stream-level flow-control problems make them stop. If your upload dies partway with a transport error rather than crawling to completion, do not treat it as a speed issue.

The practical tell is the failure mode. Slow means the progress bar moves and finishes late. This fault means the transfer errors out — commonly surfacing in a browser as a generic fetch failure — while smaller uploads through the same proxy succeed without trouble.

We hit this on our own stack with customers uploading large images, and it is worth naming separately because misfiling it wastes days. Everybody starts investigating the device's speed, and the device's speed was never the problem — the stream was being torn down. "Get a faster phone" would not have fixed it.

If a small file uploads through the same proxy and a large one does not, that is the shape of this bug, not a bandwidth limit.

When this becomes an infrastructure problem

Most of this page is diagnosis you can run with curl. It becomes an infrastructure question at the point where you cannot tell whether a slow device is a bad tower, a wedged multiplexer, or the normal ceiling — because nothing is measuring the difference for you.

That is a real gap in most setups. A dashboard that reports a device as "online" is usually reporting a heartbeat on a control channel, which stays perfectly healthy while the data path is unusable. Under load that distinction is exactly the one you need, and it is the reason we changed our own health definition to require verified cellular egress rather than a heartbeat alone — the detail is in rotation verification.

The other structural variable is whether the device is yours alone. On a shared pool, another tenant's scraping run is the fanout that wedges the multiplexer your session is riding on, and you cannot see it or act on it. A dedicated device does not make the uplink faster — nothing does — but it makes the slowness attributable, which is the difference between a fault you can fix and one you can only complain about. That is the substance of mobile vs residential proxies.

The honest limitation: none of this raises the ceiling. Dedicated hardware, better health checks and cleaner diagnostics all improve consistency. They do not add bandwidth, because the constraint is the carrier's uplink and no vendor owns that.

When a mobile proxy is the wrong tool

If raw throughput is your actual requirement, stop reading and buy something else.

Datacenter proxies are dramatically faster than any mobile proxy, and the gap is not close. They sit on wired connections with symmetric bandwidth and no radio in the path. For bulk downloads or anything measured in megabytes per second, that is the correct product, and a mobile proxy is an expensive way to be slow.

What you buy with a mobile proxy is how the address is treated, not how fast it is. Carrier addresses sit in front of large numbers of ordinary phone users, so aggressive blocking carries real collateral cost for the site — which is why they are scored more gently. That is the entire product, explained properly in what a mobile proxy actually is.

So it is a trade, and it should be made explicitly:

• Detection is the constraint — you are being blocked, challenged, or rate limited on datacenter addresses. A mobile proxy is the right tool, and 2-3 MB/s is the price.
• Throughput is the constraint — you are not being blocked, you just need volume. Use datacenter proxies. You will pay less and go far faster.
• Both — split the work. Fetch what you can from cheap, fast addresses, and reserve the mobile path for the requests that actually need the trust.

Anyone who sells you a mobile proxy on speed is selling you the wrong half of the product. If your proxy is delivering 2-3 MB/s and connecting normally, it is doing its job, and the remaining question is whether that job is the one you needed done. If instead the address stopped changing when you asked it to, that is a separate diagnosis.

Frequently asked questions

What speed should a mobile proxy give me?

Around 2-3 MB/s is normal and healthy. That figure is set by the carrier's uplink, because your download through the proxy is the phone sending data back to you. A fast phone on a strong 5G signal sitting at 2 MB/s is a correctly working proxy, not a broken one.

Why is my 5G mobile proxy slower than the advertised 5G speed?

Because the advertised number is downlink — the speed of data arriving at the phone. Proxy traffic that you download travels in the other direction, out of the phone, and carrier uplink is far narrower. You are measuring a different pipe from the one the marketing describes.

Is slow throughput the same problem as a slow connection?

No, and conflating them wastes time. Throughput is how fast bytes move once a connection exists; connect time is how long the handshake takes before any bytes move. A proxy can have a perfectly normal 2-3 MB/s transfer rate and still take 7-8 seconds to establish a connection, and those have different fixes.

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

Typically because the destination is applying extra scrutiny to a cellular address that has been active for a while. It is an external throttle applied by the site, not a defect in the proxy. Rotating on a schedule to dodge it treats the symptom rather than the cause.

One of my proxies is much slower than the others. What is wrong with it?

If a single device is slow while the rest of the fleet is normal, the likeliest cause is an unstable tower gateway at that device's physical location. Moving the device or swapping its SIM is the fix. Fleet-wide settings changes will not help a single-device problem.

Should I use a mobile proxy for large downloads or bulk data transfer?

No. If raw throughput is the requirement and you do not need to look like a residential mobile user, a datacenter proxy is dramatically faster and much cheaper. Mobile proxies buy trust from detection systems, and you pay for that trust in bandwidth.