How 4G/5G Mobile Proxy Infrastructure Actually Works

Most descriptions of mobile proxies stop at "it routes your traffic through a phone." That is true, and it explains nothing. It does not tell you why there is a server in the middle, why rotation takes the time it takes, why the speed ceiling sits where it does, or why two providers running identical hardware produce different results.

This page is the mechanism, hop by hop, with the physical constraint that governs each one. It is written for people who need to predict how the system behaves under their own workload rather than accept a vendor's summary of it.

If you want the conceptual version first — what these are for, when they help, when they do not — start with what a mobile proxy is. This page assumes you have that and want the engineering underneath it.

The full chain, hop by hop

Five components in a fixed order: your client, a relay server with a public address, a persistent tunnel between relay and device, a physical Android phone holding a carrier SIM, and the cellular radio that carries the request out. The response returns along exactly the same path, in reverse, through the same tunnel.

Written out:

your client
   │   SOCKS5 or HTTP, authenticated
   ▼
relay server  (public IP, datacenter)
   │   persistent tunnel — opened BY the phone, held open
   ▼
Android device + carrier SIM
   │   cellular radio → carrier CGNAT → public internet
   ▼
destination site

Three things about that diagram do most of the explaining.

The phone is the exit node, not the relay. The address the destination logs belongs to the carrier and was assigned to that handset. The relay never talks to the destination; it authenticates you, resolves which device is yours, and moves bytes.

The tunnel arrow points the wrong way on purpose. The relay does not connect to the phone; the phone connects to the relay and keeps that connection alive. The next section is entirely about why.

Every byte crosses the radio twice in effect. Your request goes out over cellular; the response comes back over cellular and then has to be pushed up the tunnel. That second leg is where the speed ceiling lives.

Why the phone dials out instead of listening

Because a phone on a carrier network has no address you can reach. The carrier hands it a private address behind carrier-grade NAT, so nothing on the public internet can open a connection to it. The only workable design is to invert the direction: the device dials out to the relay and holds that socket open permanently.

Carrier-grade NAT, concretely

There are not enough IPv4 addresses for every subscriber to have one, so carriers assign devices private addresses and translate them at scale through a much smaller pool of public addresses shared across many subscribers at once.

The consequence for anyone building proxy infrastructure is absolute: you cannot point your scraper at a phone. There is no port to forward, no address to publish, no firewall to open. The public address is not the phone's — it belongs to the carrier's translation layer, and it is shared.

So the phone opens an outbound connection to a server that does have a reachable address, and everything is multiplexed over it. When your request arrives at the relay it is not forwarded to the phone; it is pushed down a channel established minutes or days earlier and never closed. This is why every mobile proxy service has a server component — a structural requirement of cellular networking, not a billing intermediary.

What the control connection has to survive

Holding a socket open across a cellular link for days is harder than it sounds, and the failure modes shape the rest of the system.

• The address underneath it moves. Carrier NAT mappings expire and reassign. The tunnel has to detect a dead connection quickly and re-establish, or requests queue against a socket that no longer exists.
• Heartbeats compete with traffic. If the device's IO threads are saturated by heavy fan-out, the heartbeat starves, the relay concludes the device is dead, and it force-closes a connection that was merely busy. A dedicated heartbeat thread is what stops a busy device from being killed for being busy.
• Reconnect timing is user-visible. After a rotation the device must re-register before requests flow again, and how aggressively that is tuned is most of the difference between a rotation costing seconds and one costing minutes.

None of this appears on a feature list. All of it determines whether the proxy works at 3am under load.

Why CGNAT is also the product

The same mechanism that makes the phone unreachable is what makes its address worth paying for. Because many real subscribers share each public carrier address, blocking one is not a precision action against a bot — it is collateral damage against paying customers. Mobile IP reputation is an economic calculation, not a technical property.

Nothing about a carrier address is cryptographically special. A detection system can identify it as mobile as easily as it identifies a datacenter range. The difference is what it does next. Datacenter ranges are published and attributable, and blocking one costs a platform close to nothing because ordinary consumers do not browse from them. Carrier CGNAT ranges sit in front of a large population of genuine mobile users, and a block there generates support tickets from real customers.

So the threshold before action is higher, and blocks lift sooner. That is the whole advantage, and its limit belongs in the same breath: CGNAT raises the threshold, it does not remove it.

Mobile IPs are not treated well because they are clean. They are treated well because blocking them is expensive for the platform doing the blocking.

What happens on the device when your request arrives

The device software reads the tunnelled request, opens a matching outbound socket, and pins that socket to the cellular interface rather than whatever route the operating system would choose on its own. Bytes stream back up the same tunnel. Two details decide whether the exit is genuinely mobile: interface pinning and DNS.

Interface pinning

If the phone is also on Wi-Fi, and in a real deployment it usually is, because Wi-Fi is how you manage it — Android will route outbound traffic over Wi-Fi by default. Your "mobile proxy" is then egressing from the office router, and the destination sees a broadband IP.

Correct device software pins the socket to the cellular network explicitly, per socket, at connect time, and that pinning has to survive the network changing underneath it during a rotation. It is also the first thing to test on any provider: check the egress address while the device is plainly on Wi-Fi. If it is not a carrier address, nothing else on this page matters.

Fan-out, multiplexing, and devices that go quiet

All of a customer's concurrent connections share one tunnel, multiplexed. That is efficient, and it introduces a specific failure: under heavy fan-out, the device's IO pool gets pinned, the multiplexer wedges, and the phone goes silent while still appearing connected.

Recovery is a relay-side watchdog that notices the device has stopped answering and force-closes the tunnel so it re-establishes. It is also why heavy parallelism does not buy throughput: past a point, more concurrency degrades everything on that phone rather than adding capacity.

What rotation physically is

An airplane-mode toggle. The radio detaches from the tower, the PDP context that carried the current address is torn down, and on re-attach the device negotiates a new bearer and the carrier assigns a different address from its CGNAT pool. Every rotation API, scheduler and dashboard button in this industry is a wrapper around that toggle.

Why roughly seven seconds is a floor

The interruption is about seven seconds end to end on our fleet, and almost all of it is carrier-side radio work: detach, fresh attach, authentication against the network, bearer setup, then the control tunnel re-establishing to the relay.

None of those steps belong to the proxy provider. A provider can remove their own overhead around the toggle — we cut recovery from roughly ten minutes in an earlier version of our stack down to seconds, which was a real engineering win, but the attach itself is what a cellular attach costs. Any provider advertising instant rotation on a real device is describing something other than a radio re-attach.

The two-second tell

Because the work is physical, the duration of a rotation tells you whether it happened.

A healthy rotation takes around six seconds. A rotation that returns success in about two seconds did not change your IP: the modem accepted the airplane-mode instruction and never acted on it. The cycle completes almost instantly precisely because nothing occurred. We call this a wedged radio, and the fix is a human toggling airplane mode on the physical handset.

This is why "the rotation API returned 200" is a weaker claim than it sounds: a 200 usually means the device acknowledged the command, not that a new address exists. Confirming the second requires reading the exit IP back and comparing it, and the two-minute test works on any provider.

Whether you should be rotating at all is separate. Rotation destroys identity on purpose, which is exactly wrong for account work — that trade-off is dedicated vs rotating.

Throughput: your download is the phone's upload

Roughly 2-3 MB/s per device is the realistic ceiling, and it is set by the cellular uplink. When a phone acts as a proxy, everything the destination sends back has to be pushed up from the phone to the relay before it reaches you. Cellular networks allocate far less capacity upward than downward.

This is why the headline 5G downlink figure is the wrong number to reason with. That figure describes content arriving at a phone for a human to consume. In proxy work the phone is a relay, and the payload direction that matters is the one the network deliberately starves.

• A single device is not a bulk pipe. If you need sustained high throughput, mobile is the wrong tier and datacenter or residential is the honest answer.
• Concurrency does not create bandwidth. Parallel connections split the same uplink and, past a point, wedge it.
• Large uploads are the hard case. Sending a big file out fights the same constraint from the other side, and a tunnel without proper flow control will drop the stream rather than slow it down.

Anyone quoting datacenter-grade speeds on a mobile IP is measuring something that did not cross a radio.

DNS: resolved on the device, or leaked from the datacenter

Where the hostname gets resolved decides whether the request is internally consistent. Resolve on the device and DNS goes to the carrier's resolvers, matching the carrier IP the destination sees. Resolve at the relay and DNS comes from a datacenter while the TCP connection comes from a carrier network. That contradiction is observable.

When your client sends a hostname rather than an IP, which SOCKS5 with remote resolution and HTTP CONNECT both do — something has to turn that name into an address. If the relay does it, the recursive query originates from the datacenter.

Two separate problems follow:

Location leakage. DNS-based geolocation now says datacenter while the IP says carrier. Any system correlating the two sees a mismatch a real phone would never produce.

Wrong answers. Large sites return different addresses depending on where the query came from. A datacenter-resolved answer can send the phone to a CDN edge nowhere near it, producing slow connects and occasional anycast misroutes that look like a broken proxy but are a resolution problem.

Resolving on-device fixes both: the query goes out over cellular, the carrier answers, and the phone reaches the edge a real subscriber there would have been given. It is also why your client-side scheme matters — socks5:// resolves locally on your machine, socks5h:// sends the hostname through. Getting that backwards is one of the most common setup errors in proxy work, covered in SOCKS5 vs HTTP proxies.

One related failure worth knowing by its signature: if SOCKS5 with a hostname fails in hundredths of a second while SOCKS5 to a literal IP works, that is a stale resolver cache on the device, not a connectivity fault. The test and the fix are here.

Health checking: a heartbeat is not egress

A device answering a heartbeat is not a device that can carry traffic. The control tunnel and the cellular data path fail independently, and the tunnel is the one that stays up. Real health checking means pushing an actual request through the device's cellular connection and marking it healthy only if that request completes.

The failure mode is common. The phone maintains its control connection, so heartbeats are answered on schedule and the dashboard shows green — meanwhile the radio is unusable and every request fails against a proxy that insists it is online.

The version that means something is heartbeat plus verified cellular egress: the relay periodically drives a real request out through each phone's radio and marks the device healthy only when it comes back. One warning for anyone building it — your probe target must not rate-limit you. Point a whole fleet at a common IP-echo service and you get throttled into fleet-wide false negatives. A generate_204-style connectivity endpoint is designed for this and will not push back.

It also has to separate a device fault from a network event. One device failing is a device problem; rotation-failure rate climbing across many devices at separate sites simultaneously is a carrier event, and the right response is to wait rather than mass-reboot.

4G vs 5G, and what the radio generation changes

Less than the marketing implies. A 4G address and a 5G address come from the same carrier pools and carry the same class of reputation; no anti-bot system scores a request higher for arriving over 5G. The generation affects latency and raw radio capacity, both of which sit behind the uplink constraint anyway.

Where 5G genuinely helps is connect latency and headroom under contention — a 5G device on a busy tower degrades more gracefully. What it does not do is move the throughput ceiling, because that ceiling is an uplink allocation decision rather than a downlink capability. Buying 5G for faster proxy downloads is buying the wrong axis of the same product.

How we run this, and what it still cannot do

Our fleet is physical Android devices on US carrier SIMs, one customer per device, each holding a persistent tunnel to a relay that authenticates your SOCKS5 or HTTP session and pushes it down to the phone. Hostnames resolve on the device. Rotation is on demand rather than on a timer you did not choose.

Two implementation choices matter most, and they are the ones this page argues for.

Every rotation records its exit address, not a success flag, but the address before, the address after, and the elapsed time. That makes the two-second tell measurable instead of anecdotal, and a rotation that changed nothing shows up in the data rather than hiding behind a 200. Most providers cannot answer that question about their own fleet, including us until we built it.

Online means verified egress. The relay drives a real request through each phone's cellular connection and marks it healthy only when that request completes. A device with a live heartbeat and a dead radio reads as offline, which is the truth.

Now the limits, because a page about physical constraints that ends without any would be dishonest. We cannot make rotation faster than the radio attach — roughly seven seconds, and no vendor owns that. We cannot raise the uplink ceiling; 2-3 MB/s per device is the carrier's allocation, not a hardware problem we can buy our way out of. A wedged radio still needs a human to toggle airplane mode on a physical handset; what we changed is how fast anyone finds out. And our egress is IPv4-only today, so on the small number of platforms that specifically expect mobile clients over IPv6, that is a genuine gap rather than a rounding error.

What this architecture cannot do

Everything above describes one input to a detection system that weighs many. A carrier IP with correct DNS, verified egress and honest rotation is still just a network signal, and network signals are the easiest part of the stack to get right.

It does not touch browser fingerprinting. Canvas, WebGL, fonts, screen metrics, timezone and TLS handshake characteristics travel with your client, and twenty identities sharing one fingerprint are one identity with twenty logins regardless of how many carrier addresses they arrived from. It does not touch behavioural detection, automation artefacts, or account history, and per-account rate limits do not care what IP a request came from.

There is also the counter-intuitive one: rotating harder can make things worse. On platforms that weight consistency, an identity whose network location changes constantly scores below one that has behaved reasonably from the same address for weeks. The mechanism on this page is neutral about how you use it — when to hold an address and when to burn it is a different decision entirely.

Diagnose which signal is failing before buying infrastructure that fixes a different one. If it is IP reputation, everything here applies. If it is not, the most carefully engineered mobile proxy in the world changes nothing, and the honest scope of what these fix is the page to read next.

Frequently asked questions

How does a mobile proxy actually route my traffic?

Your client connects to a relay server with a public address and authenticates. The relay pushes your request down a tunnel that a physical Android device opened earlier and holds open. The device makes the request over its cellular radio, and the response travels back up the same tunnel to you.

Why does a mobile proxy need a server at all — why not connect to the phone directly?

Because you cannot reach the phone. Carriers place subscriber devices behind carrier-grade NAT, so the handset has no publicly routable address and cannot accept an inbound connection. The device has to dial out to a relay and keep that connection open, and the relay is what you connect to instead.

What physically happens during an IP rotation?

The device toggles airplane mode. The radio detaches from the tower, the PDP context carrying the current address is torn down, and on re-attach the carrier assigns a different address from its CGNAT pool. Around seven seconds of interruption, most of it spent on the radio re-attach itself.

Why can't rotation be faster than about seven seconds?

Because the time is spent detaching from the tower and completing a fresh attach and bearer setup. That is carrier-side radio work, not queueing in the provider's software. A provider can remove their own overhead around it, but not the attach itself.

Why is a 5G mobile proxy still only 2-3 MB/s?

Because the constraint is the uplink, not the downlink. 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, and cellular networks allocate far less capacity upward than downward.

Does DNS resolution happen on the phone or on the server?

It depends on the implementation, and it matters. Resolving on the device means queries go to the carrier's resolvers and match the carrier IP the destination sees. Resolving at the relay means DNS comes from a datacenter while the connection comes from a carrier — a mismatch that is detectable.