Rotation Says Success But the IP Never Changes — How to Diagnose It

You called the rotation endpoint. It returned success. You read the exit IP back and it is the same address you had a minute ago.

This is the single most common mobile proxy support ticket, and the reason it eats days of debugging is that at least four completely different faults produce that identical symptom. One is fixed by touching the phone for three seconds. One is fixed by moving the device to a different room. One is fixed by doing absolutely nothing. And one is not a rotation problem at all.

Guessing between them is expensive. Measuring separates them in about two minutes, and the measurement is a stopwatch.

Why a success response is not a claim about your IP

Most rotation APIs return success when the device accepts the rotation command. That is a different event from a new address being assigned, and the two are separated by several seconds of physical radio work. If nothing in the chain reads the exit IP back afterwards, nothing in the chain can tell the difference.

The typical implementation is a short chain: your request arrives at the API, the API forwards a command to the device, the device acknowledges it, and the API returns 200 OK. Every step in that sequence is honest. None of them involves reading the resulting exit address.

So when the radio silently fails to re-attach, no component notices, and the success flag stays true. The response is accurate about the thing it is actually reporting. It just is not reporting what you assumed.

This matters beyond one bad rotation. If your workflow treats the success flag as proof, every downstream decision — retry logic, session assignment, ban attribution — inherits an error you never see. We cover the verification side of this in detail in proving a rotation worked.

The elapsed-time tell: two seconds versus six

A rotation that returns success in about two seconds did not change your IP. A genuine rotation takes roughly six seconds, because the radio has to detach from the tower and re-attach before a new address exists. That four-second gap is the diagnostic, and it is visible from outside without any cooperation from your provider.

The gap exists because a real rotation is physical. The radio drops its connection to the tower, the attach handshake runs again, and a new session context is established with a new address. None of that is instant.

When the modem accepts the airplane-mode toggle without acting on it, that work never happens. The cycle completes almost immediately — because nothing occurred. Two seconds is not a fast rotation. Two seconds is the sound of no rotation at all.

This is the most reliable field tell we have, and it works without trusting anybody's dashboard. A wall clock is enough.

The rest of this page walks each row.

Measure it yourself: the curl and time recipe

Record the exit IP, time the rotation call, record the exit IP again. Repeat five or six times. This works against any provider, needs no special access, and separates the fast-fake rotation from the genuine one more reliably than any dashboard indicator you have been given.

Step 1 — read your starting address.

curl -s -x http://USER:PASS@your-proxy-host:PORT https://api.ipify.org

Step 2 — rotate, and time it.

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

Step 3 — read the address again.

curl -s -x http://USER:PASS@your-proxy-host:PORT https://api.ipify.org

If you would rather have it in one pass, this loop prints elapsed seconds next to the before and after addresses:

for i in 1 2 3 4 5 6; do
  BEFORE=$(curl -s -x http://USER:PASS@your-proxy-host:PORT https://api.ipify.org)
  START=$(date +%s.%N)
  curl -s -o /dev/null "https://your-provider/rotate/YOUR_TOKEN"
  END=$(date +%s.%N)
  sleep 8
  AFTER=$(curl -s -x http://USER:PASS@your-proxy-host:PORT https://api.ipify.org)
  echo "run $i  elapsed=$(echo "$END - $START" | bc)s  $BEFORE -> $AFTER"
done

Run it six times rather than once. A single sample misleads in both directions: a queued rotation can make a fake one look real, and a slow hop can make a real one look suspicious. Six runs make it obvious — a wedged radio produces a wall of two-second lines with an unchanged address on every row.

If the elapsed time is consistently around two seconds and the address never moves, stop debugging your script. The problem is on the device, and no amount of retry logic will reach it.

Fault one: the wedged cellular radio

The modem accepts the airplane-mode toggle, the operating system reports it as done, and the radio never actually detaches from the tower. Everything up the stack sees success. The fix is one manual airplane-mode toggle on the physical device, and it takes about three seconds.

What makes this state confusing is that it is not an error anywhere. No exception, no timeout, no failed call. The command was accepted, the acceptance was reported truthfully, and the radio simply did not act.

Two things this is not, both of which we have watched people spend real money on:

It is not a carrier problem. The carrier is fine. Every other device on the same carrier, in the same room, rotates normally. Escalating to carrier support produces nothing because there is nothing on their side to find.

It is not a SIM problem. Replacing the SIM appears to work, because pulling the SIM tray forces the radio to reset — which is the same thing the airplane toggle does, for free. The SIM was never faulty.

Toggle airplane mode on, wait a couple of seconds, toggle it off. Then re-run the timing loop above. A cleared device goes straight back to six-second rotations.

Fault two: rotations that take 60-120 seconds

A rotation taking a minute or two, or an exit IP that drifts to a new address without being asked, is an unstable tower gateway rather than a software fault. The CGNAT assignment on that gateway is not holding. Move the device to a different physical location or swap to a different SIM — adjusting rotation timing changes nothing.

This is the opposite failure from a wedged radio, and it gets misdiagnosed the same way every time: somebody sees slow rotations, assumes a queue or a timeout, and starts tuning intervals. The timing is not a setting. It is how long that tower gateway is taking to hand out an address.

The tell that distinguishes it from everything else on this page is drift: the address changes when you did not ask it to. A wedged radio never changes the address. A healthy device changes it only on command. A device behind an unstable gateway changes it on its own schedule.

Because it is a location problem, the fixes are location fixes. Physically moving the device — sometimes only a few metres, sometimes to a different site — is the highest-value thing to try. A different SIM, which may attach to a different gateway, is the second.

Fault three: many devices failing at the same time

If rotation failures appear across many devices simultaneously, especially devices in different physical locations, and the failure message is that cellular did not return after airplane-off, the carrier is having an event. The correct response is to do nothing and wait.

The pattern is distinctive once you have seen it. Devices drop one at a time, gradually, rather than all at once — a code bug or a service restart takes everything down together, while a carrier event walks through the fleet over hours. Failures appear at physically separate sites, which rules out anything local. And devices come back on their own, without intervention.

Two things worth saying plainly, because both are counter-intuitive under pressure:

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

Do not rotate your way out of it. Rotation is the operation that is failing. Retrying it in a loop adds load to the exact mechanism that is broken.

The useful signal here is rotation-failure rate rather than device-online count. Online counts lag badly — a device can hold a healthy control-channel heartbeat for minutes with a useless radio, which is why "online" is the most misleading number in this industry. Failure rate moves immediately.

Fault four: SOCKS5 with a hostname fails instantly

This one is rarer and does not belong to the rotation family at all, but it presents as "one proxy is broken" and gets filed alongside them. The signature is precise: SOCKS5 requests using a hostname fail in about 0.03 seconds with connection code 000, while SOCKS5 to a literal IP works and plain HTTP works.

That combination is diagnostic. A near-instant failure means nothing left the machine — there was no connection attempt to time out. And the fact that only the hostname path fails, while the same destination reached by literal IP succeeds, points at name resolution rather than connectivity.

The cause is a stale resolver cache on the device. The fix is one rotation, which forces the connection to be re-established and the resolver state to be rebuilt. Roughly a six-second interruption, and the proxy behaves normally afterwards.

Worth testing explicitly before you assume this, because the test is trivial:

curl -s --socks5-hostname USER:PASS@host:PORT https://api.ipify.org -w " %{time_total}\n"
curl -s --socks5 USER:PASS@host:PORT https://api.ipify.org -w " %{time_total}\n"

If the first line fails in hundredths of a second and the second returns an address, you have found it.

When this becomes an infrastructure problem

Everything above is diagnosis you can run yourself. There is a point past which it stops being diagnosis and becomes operations: when you have more devices than you can hold in your head, and you need to know which of these four faults is happening without touching each one.

At that scale the requirement changes shape. You stop wanting a rotation endpoint and start wanting a rotation record — the exit address before, the address afterwards, and how long the call took — because the elapsed-time tell only works as an alert if something records it on every rotation, not just the ones you watch.

That is the specific thing we built. We capture the exit address on every rotation across the fleet, so a rotation that reported success without changing anything is visible in our data rather than hidden behind a flag, and health is defined as a heartbeat plus verified cellular egress rather than a heartbeat alone. A dedicated device per customer is what makes it attributable — on a shared pool you cannot tell whose rotation wedged whose radio.

The honest limitation: none of that stops a radio from wedging. It shortens the gap between the wedge and somebody knowing about it. The fix is still a human toggling airplane mode on a physical phone, and any provider who tells you they have engineered that away is describing a device they do not have.

The floor you cannot engineer away

Two limits, stated openly, because they are the ones people expect a better provider to remove.

Rotation has a hard floor of roughly seven seconds of interruption. That is physical re-attach time — the radio detaching and completing a fresh handshake with the tower. Earlier versions of our stack took about ten minutes to recover after a rotation, and cutting that to seconds was a genuine engineering win. The remaining seconds are not an optimisation target. They are what a cellular attach costs.

A verified new address is not automatically a better address. Knowing the rotation worked tells you the IP changed. It says nothing about that address's reputation or history. A fresh address is not inherently safer than the one you just left — a separate problem, covered in what a mobile proxy actually solves and the rate-limiting guide.

If your rotations are verified and correctly timed and results are still poor, the address is probably not your constraint. Look at request rate, session continuity, and whether you are rotating when you should be staying put. If the complaint is speed rather than blocking, that is a different diagnosis entirely.

Frequently asked questions

Why does my proxy IP stay the same after a successful rotation?

Almost always because the success response confirmed that the device accepted the rotation command, not that a new address was assigned. If the call came back in about two seconds, no rotation occurred — a real one takes roughly six seconds of physical radio work.

How long should a mobile proxy rotation take?

About six seconds for the rotation itself, with roughly seven seconds of connectivity interruption while the radio re-attaches to the tower. That is physical re-attach time, not a queue delay, so it is not something a provider can remove entirely.

What is a wedged cellular radio?

The modem accepts the airplane-mode toggle and the operating system reports success, but the radio never actually detaches from the tower. The cycle finishes almost instantly because no real work happened, which is why the elapsed time collapses to around two seconds.

Will changing the SIM or the carrier fix an IP that never changes?

For the fast-rotation case, no. A wedged radio is cleared by one manual airplane-mode toggle on the physical device. Swapping the SIM or moving carriers is the correct response to a different fault — slow rotations and drifting IPs — not this one.

My rotation takes over a minute. Is that the same problem?

No, it is the opposite fault. Long rotations point at an unstable tower gateway where the CGNAT assignment is drifting, which is a network-location problem. Moving the device or swapping the SIM helps; adjusting rotation intervals or timeouts does not.

Why does SOCKS5 fail instantly on one proxy while HTTP works fine?

If SOCKS5 with a hostname fails in about 0.03 seconds while SOCKS5 to a literal IP works and HTTP works, that is a stale resolver cache on the device rather than a rotation problem. One rotation forces a reconnect and clears it.