Most Mobile Proxies Can't Prove a Rotation Worked — Here's How to Test Yours

Every mobile proxy provider offers IP rotation. Far fewer can tell you whether a given rotation actually worked.

This is not usually dishonesty. It is an architectural gap that most providers have never had a reason to close, and it produces a specific, frustrating failure: the API returns success, your script logs success, and your IP is exactly what it was before.

Here is how that happens, how to detect it, and how to test whatever provider you are using today.

Why a rotation can report success and change nothing

Most rotation endpoints confirm that the device accepted the command, not that a new address was assigned. Those are different events separated by several seconds of physical radio work, and only the first one is easy to observe.

The typical implementation looks like this: the API receives your rotation request, forwards a command to the device, the device acknowledges it, and the API returns 200 OK. Nothing in that sequence reads the resulting exit IP. If the radio silently fails to re-attach, no component in the chain notices.

Once you understand that, the "successful rotation, unchanged IP" reports stop being mysterious. The success is real — it just refers to a different thing than you assumed.

The elapsed-time tell

A rotation that completes in about two seconds did not change your IP. A genuine one takes roughly six.

That gap exists because a real rotation involves physical work: the radio drops its connection, the tower handshake happens again, and a new PDP context is established. That takes seconds. When the modem accepts the airplane-mode toggle without acting on it, the whole cycle completes almost instantly, because nothing actually occurred.

This is the single most useful diagnostic we have, and it took a customer complaint to surface it. The customer's script was doing everything correctly. The API was returning what it promised. The device was lying to both of us.

That last row matters more than it looks, and it leads directly to the next section.

One device failing is a device problem. Many failing at once is not.

If a single device fails to rotate, investigate the device. If rotation-failure rate rises across many devices simultaneously — especially devices in different physical locations — the carrier is having an event and the correct response is to do nothing.

We learned this the expensive way. During a nationwide carrier event, our fleet went from 104 online devices down to 70 over roughly five hours. No code had shipped. No configuration had changed.

The pattern was distinctive once we had seen it:

• Devices dropped one at a time, not all at once. A code bug or a service restart takes everything down together; a carrier event walks through the fleet gradually.
• Rotations failed with the radio dropping and never re-attaching.
• Failure rate climbed across devices at physically separate sites, which rules out anything local.
• 32 of 34 affected devices recovered on their own without intervention.

Two things worth stating plainly, because both are counter-intuitive:

Do not mass-reboot during a carrier event. We tried. It does not help, and it converts a partial outage into a complete one while every device simultaneously attempts to re-handshake against an already-struggling network.

Rotation-failure rate is a better health signal than device-online count. Online count lags badly — a device can hold a stale heartbeat for minutes while its radio is useless. Failure rate moves immediately.

Why "online" is the most misleading number in this industry

A device answering a heartbeat is not a device that can carry your traffic. Most dashboards report the first and label it as the second.

The failure mode is straightforward. The phone maintains its control connection to the relay, so the heartbeat is healthy and the dashboard shows green. Meanwhile the cellular radio is dead. Your requests fail against a proxy that insists it is online.

The fix is to stop trusting the control channel as a proxy for the data path. Our relay now pushes a real request through each phone's cellular connection and only marks it healthy when that request completes. Online means heartbeat plus verified cellular egress, not heartbeat alone.

One implementation detail for anyone building this themselves: your probe target must not rate-limit you. We initially used a common IP-echo service and got throttled into false negatives across the whole fleet — every device reported unhealthy because the probe target had had enough of us. A generate_204-style endpoint designed for connectivity checking is the right choice.

Test your current provider in two minutes

This works against any provider. You need curl and the ability to time a command.

Step 1 — record your starting IP.

curl -x http://user:pass@your-proxy-host:port https://api.ipify.org

Step 2 — rotate, and time it.

time curl "https://your-provider/rotate/YOUR_TOKEN"

Step 3 — read the IP again.

curl -x http://user:pass@your-proxy-host:port https://api.ipify.org

Now interpret:

• Returned in ~2s, IP unchanged → the rotation did not happen, and the success response was about command acceptance
• Returned in ~6s, IP changed → genuine rotation
• Returned fast, IP changed → possible, if the provider queues rotations and you happened to read after an earlier one completed. Repeat several times before concluding anything.
• IP never changes across repeated attempts → either a wedged radio or a provider that is not really rotating

Run it five or six times rather than once. A single result can mislead in either direction.

If your provider cannot tell you what the exit IP was after a rotation, they are not in a position to promise the rotation worked. That is worth knowing before you build a workflow on top of it.

What we changed, and what it cost us to learn

We had the same blind spot. Until mid-2026 we captured the exit IP on only a fraction of rotations — the ones where a customer happened to trigger a code path that read it back. We could not have answered the question this article poses, about our own fleet.

We now record the exit address on every rotation, on every device. That means a rotation which did not change the IP is visible in our data rather than hidden behind a success flag, and it is what makes the elapsed-time tell above measurable rather than anecdotal.

We are not claiming this is exotic engineering. It is a small amount of work that most providers have not done because nobody was asking. Ask.

The honest limits

Two things this does not fix, stated openly:

Rotation speed has a floor. Roughly seven seconds of interruption while the radio re-attaches, and that is physical. We reduced this from about ten minutes in an earlier version of our stack, which was a real improvement, but the remaining seven seconds are not going anywhere.

Verification does not make an IP trusted. Knowing your rotation worked tells you the address changed. It says nothing about whether the new address has a good reputation, and a fresh address with no history is not automatically better than the one you had. That is a separate problem, covered in what a mobile proxy actually solves.

Frequently asked questions

How do I test whether my provider's rotation is real?

Record your exit IP, trigger a rotation while timing it, then record the exit IP again. If the call returned success in about two seconds and the IP is unchanged, the rotation did not happen. Repeat a few times — a single fast success can be a cached response.

Why would a rotation report success without changing the IP?

Because the provider is reporting that the device accepted the command, not that a new address was assigned. If nothing ever reads the exit IP back afterwards, there is no mechanism by which they could know the difference.

What causes a wedged radio?

The modem accepts the airplane-mode toggle and the OS reports success, but the radio never actually detaches from the tower. The cycle completes almost instantly because no real work occurred. A manual airplane toggle on the physical device clears it.

Is a 60-second rotation broken?

Not broken, but not healthy either. Long rotations usually indicate an unstable tower gateway where CGNAT assignment is drifting. It is a network-location problem, so moving the device or swapping the SIM helps; adjusting rotation timing does not.

How long should a normal rotation take end to end?

On our fleet, roughly seven seconds of connectivity interruption while the radio re-attaches. That is the physical re-attach time, not a queue delay, so it is not something a provider can optimise away entirely.

Why does my dashboard show a proxy online when it isn't working?

Almost always because the dashboard is reporting a heartbeat over the control channel rather than testing the data path. The two can diverge — the control connection stays up while the cellular radio is unusable.