When Rotating Too Fast Gets You Barred Upstream
A customer messaged me saying every one of his proxies was down. The dashboard agreed, showing the whole batch offline, which is the kind of message that makes you assume something physical broke. A hub, a power strip, a cable.
Nothing was unplugged. The modems were attached to the network with normal signal on every one of them. The carrier had stopped passing data for those sessions, because his script had been tearing down and rebuilding the connection every few seconds for hours, and from the network’s side that reads as abuse.
Most people scraping through mobile proxies never consider this failure mode. You think about the target blocking you, or your provider’s pool going bad. You do not think about the mobile network operator deciding you are a problem.
Rotation on mobile is not a routing decision
On a datacentre or residential proxy, rotating usually means the provider routes your request through a different exit in a pool. It is a software decision, effectively instant and effectively free.
On a real mobile proxy it is a different operation entirely. There is a physical modem with a SIM attached to a carrier network. That attachment includes a data session, and your public IP is assigned as part of it. Getting a new IP means ending that session and negotiating a new one.
The device asks the network to establish a data context, the network verifies the subscription is permitted, an address is allocated, and a tunnel is set up to the gateway that routes your traffic out. Rotation runs that whole sequence again. It is a real transaction with carrier infrastructure, which is why mobile rotation takes seconds rather than milliseconds. People arriving from datacentre pools often read that delay as a slow provider. It is just what talking to a phone network costs.
It is also a discrete, countable event from the operator’s point of view.
What the carrier sees
A script rotating every five seconds produces hundreds of session setups and teardowns per hour from a single SIM, and keeps producing them for as long as the job runs. No handset behaves that way. A phone does this a handful of times a day: moving between cells, losing signal in a lift, toggling airplane mode. It does not do it seven hundred times before lunch.
Carriers run automated protections against this, because signalling load is a genuine cost and this pattern matches a known category of network abuse. Exact thresholds are not published, they differ between operators, and I only have visibility into the carriers I actually run, so treat what follows as the shape of the behaviour rather than a specification.
What I have consistently seen is that the penalty lands on the data session rather than the SIM as a whole. The device stays attached. It reports registered, signal looks normal, status lights are fine. The data context is barred, so nothing flows. That gap between what the device reports and what actually works is why this takes so long to diagnose.
Your monitoring will lie to you about it
Most proxy management software decides whether a modem is up by making an outbound request through it and seeing what comes back, usually to an IP echo service. Reasonable design. But when the carrier has barred the session, that request fails and the software reports the modem as down, which sends you hunting for hardware faults. Cables, hubs, power, USB resets. I have lost real hours on that path for a problem that was never physical.
Ask the device instead of asking your software about the device. Nearly every USB modem exposes a small web interface on its own gateway address, usually somewhere in the 192.168 range, and it will tell you what the device believes: registration state, signal, what the carrier says about the connection. If the device reports attached with good signal while your proxy layer calls it dead, the problem sits between the carrier and you, not between you and the hardware. That check takes ten seconds and splits two completely different investigations.
Telling a carrier bar from a target block
The symptoms diverge cleanly once you know what to compare.
A target block is selective. That one site returns 403s or captchas or serves you a different page, while everything else through the same proxy works normally. Curl any other domain and you get a clean response. The block follows the destination.
A carrier bar is total. Nothing passes. Not the target, not an IP echo service, not a plain DNS lookup. The block follows the connection. If you cannot reach a single thing through that proxy while the modem reports healthy signal on its own interface, stop debugging your scraper. You have been rate limited by the mobile network.
There is a third case worth separating: your provider may have its own rotation limits and could be throttling or refusing rotation calls before they ever reach the carrier. That presents as the rotation endpoint erroring or simply not changing your IP, while data continues flowing on the existing session. Comparatively benign, and usually solved by reading your provider’s documented rate limits.
Rebooting is the wrong instinct
The first reaction is always to power cycle the device, and that is half right. A reboot forces a full detach and reattach, and sometimes you come back with a working session.
But if the bar applies to the subscription rather than to that particular session, rebooting walks you straight back into it while adding more reattach events to a network that already flagged you. I have watched someone reboot a modem in a loop for twenty minutes trying to fix this. It is the same mistake as the retry loop that caused it, performed by hand.
What clears it, in my experience, is time. Leave the SIM alone and come back later. That is an unsatisfying answer and I cannot give you a duration that holds across carriers, but the pattern is consistent enough that the right move on a suspected bar is to pull that device out of the pool and let it sit rather than keep poking it.
Cap the blast radius in your own code
Put a cooldown on rotation per device, enforced in code, rather than trusting every script that touches the pool to behave. After a rotation, that SIM cannot rotate again until a fixed interval elapses, and requests inside that window get refused or queued.
The specific number matters less than the limit existing. What you are preventing is the runaway case.
Most of the damage I have seen does not come from someone deliberately choosing to rotate every second. It comes from a scraper that gets a bad response, whose error handler rotates and retries, and the next response is also bad because the real problem has nothing to do with the IP, so it rotates and retries again. Now you have a tight loop generating carrier signalling load until something gives. The retry logic amplifies one problem into a much worse one. A cooldown is not there to constrain normal use, it is there to cap that.
You probably need less rotation than you think
Rotating on every request is a habit imported from datacentre pools where it costs nothing, and on mobile it is often counterproductive.
Mobile addresses are shared by design. Carriers put many real subscribers behind the same addresses, and that shared quality is most of why targets trust them. Holding one for a while looks more like a person than cycling through a new address every few seconds.
A sticky session is not a downgrade. For plenty of targets it is strictly better, because session continuity is what a real user has. Someone browsing a site keeps the same address for the whole visit. Requests to one site arriving from six addresses inside a minute is itself a signal, and you built it while trying to hide.
Rotate when there is a reason: a finished batch, an actual block signal from the target, the end of a session you deliberately time-boxed. A five second timer set because more seemed better is not a reason.
In priority order: add a per-device cooldown in the rotation code path, make your health check interrogate the device rather than only testing traffic through it, and when something looks totally dead, check whether anything at all passes before assuming the target blocked you.
I cannot give you the rotation rate that trips a given operator. It varies by carrier and I would be inventing numbers if I tried. What I can tell you is that the ceiling is real, it sits well below what an unthrottled retry loop produces, and recovering from a barred session costs far more time than the rotation ever saved.
If you want the deeper breakdowns on proxy types, rotation setups, and honest comparisons of providers we’ve actually tested, head back to the homepage.
Get new guides and videos first — join the Telegram channel.