What happens to your connection when a carrier reassigns the IP block

The call that started this article

A few months back, someone running an automation job on one of our SIMs messaged us confused because a session that had been stable for six hours suddenly reset with no warning, and the “new” IP it got assigned started throwing CAPTCHAs on a site that had been fine all morning. Nothing broke on our end. The device didn’t reboot. The SIM didn’t fall out. What happened is normal, boring, and almost never explained clearly: the carrier reassigned the IP block the device was sitting in. This is what that actually means, mechanically, and why it matters if you’re running anything that depends on a stable-feeling mobile IP.

Mobile IPs were never meant to be yours

SingTel, M1, and StarHub all run their mobile data networks behind carrier-grade NAT (CGNAT). Your phone or USB modem doesn’t get a dedicated public IP the way a fixed broadband line might. Instead, the carrier’s core network (the PGW in LTE, the UPF in 5G) hands out public addresses from a shared pool, and thousands of subscriber devices sit behind each address at once, distinguished only by port. When your device attaches to the network, or when its current session expires and refreshes, it gets assigned a public IP out of whatever pool is currently active on that gateway.

That pool isn’t static. Carriers manage it the same way any large network operator manages scarce IPv4 space: they resize pools based on load, they move blocks between gateways during maintenance, they consolidate ranges after infrastructure changes, and they return addresses to a shared pool once a session’s timer runs out so the address can be handed to someone else. None of this is done with your workload in mind. It’s done to keep the network running efficiently for millions of subscribers, and an individual device’s IP is just an entry that gets reused, moved, or retired as needed.

What actually happens the moment it flips

When a carrier reassigns the block your device is sitting on, the existing NAT mapping between your device and its old public IP is torn down. Any connection that was open and depending on that mapping stops working immediately, not gracefully. A TCP session gets a reset or just times out because packets addressed to the old translated IP no longer route to your device. A websocket drops. An SSH tunnel dies. A long scraping session that assumed the IP would hold for the next hour finds itself talking to nobody.

Your device then attaches again, or its session refreshes, and gets a new public IP handed out from whatever pool is active at that moment. That new IP might come from the same general block as before, or it might come from a completely different range, possibly even registered to a different city-level geolocation bucket in commercial IP databases like MaxMind. This is why you’ll sometimes see a Singapore mobile connection briefly show up as being in a neighboring region in some geo-lookup tools right after a reassignment, before the databases catch up.

The part nobody tells you: you inherit the IP’s history

Here’s the detail that actually matters for anyone doing scraping, automation, or account management. An IP address isn’t just a number, it’s a reputation. Services like Spamhaus, various fraud-scoring engines, and individual site anti-bot systems keep records tied to the address itself, not to the physical SIM or device behind it. Because a single CGNAT public IP is shared across potentially thousands of subscribers at once, that reputation is a shared resource too.

If your device gets handed an IP that a few hundred other subscribers on the same carrier were also using in the last few hours, and one of them was running something aggressive, you can land on an address that’s already flagged. You didn’t do anything wrong. You just got assigned a block with baggage. Conversely, you can get lucky and land on a clean IP that nobody’s touched with anything suspicious. There’s no way to know in advance which one you’re getting, because the carrier’s allocation logic has nothing to do with reputation, it’s purely about capacity and routing.

This is also why a mobile IP that’s been “clean” and stable in your workflow for days can suddenly start throwing friction with no code change on your end. The IP didn’t get worse. You got moved to a different one, and that one has a different history.

What this looks like from inside a real farm

Running actual hardware with SingTel, M1, and StarHub SIMs instead of some virtualized substitute means we deal with this constantly, because it’s not a simulated behavior, it’s just how mobile networks work. A device’s public IP is not a fixed asset we control, it’s something the carrier’s core network decides on its own schedule. We monitor for IP change events on each device so we know the moment a reassignment happens rather than finding out because a job failed. When a device’s address changes, any session tied to the old IP has to be treated as dead, not paused, because trying to resume against a torn-down NAT mapping just produces more resets.

We also don’t treat a freshly assigned IP as a known quantity. Right after a reassignment, we have no information about what that specific address has been used for by other subscribers on the same pool. Hammering it immediately with the same aggressive request pattern that worked on the previous IP is a good way to find out the hard way that it’s already flagged somewhere. A short warm-up period, lower request volume, ordinary-looking traffic first, gives you a read on whether the new address is behaving normally before you lean on it.

What you can actually do about it

You can’t prevent carrier-side reassignment. It’s not a setting, it’s not something an SLA changes, and it’s not specific to any one operator, it’s how CGNAT works on every mobile network in Singapore and pretty much everywhere else. What you can do is build around the fact that it will happen.

Don’t design a workflow that assumes an IP is permanent. If a task needs to run for hours, structure it so a mid-task reassignment means a graceful reconnect and resume, not a hard failure. Keep sessions reasonably short by design instead of stretching a single connection as far as it’ll go, because the longer a session runs, the more you’re betting on an address that could disappear at any point without warning. Log IP changes so that when something starts behaving oddly, you can correlate it against an address change instead of assuming your automation broke. And when you do land on a new IP, treat the first few minutes as a probe, not a green light.

The honest bottom line

A carrier reassigning an IP block isn’t a malfunction and it isn’t something aimed at you. It’s routine address pool management happening on a network that was built to serve millions of phones, not to give any single device a stable, dedicated identity. If you’re using mobile IPs for scraping, browser automation, or running multiple accounts, the churn is a feature of the medium, not a bug to work around once and forget. The operators who get the fewest surprises are the ones who plan for the reassignment instead of hoping it won’t happen mid-job.

If you want to see how this plays out on real SingTel, M1, and StarHub connections instead of taking our word for it, our YouTube channel walks through it on actual hardware, and our site has more on how we run the farm.

Get new guides and videos first — join the Telegram channel.