Keeping long-lived connections alive on a mobile line

If you’ve ever run a scraper, a WebSocket-based automation session, or any long-poll job over a mobile connection and watched it silently die after a few minutes with no error, you’ve run into the gap between how mobile networks are built and how most networking code assumes the internet works. This isn’t a bug in your script. It’s the network doing exactly what it’s designed to do.

We run a real SIM farm here (SingTel, M1, StarHub, physical modems, no simulated anything), and connection drops on long sessions are one of the most common things people ask us about. So let’s go through why it happens and what actually helps.

Mobile networks were not built for long-lived sessions

A home fibre connection or a server in a datacenter gives you a stable public or semi-stable NAT’d IP and a network stack that mostly stays out of your way. A mobile line is different on almost every layer that matters for a persistent connection:

• Carrier-grade NAT (CGNAT). Nearly every mobile carrier, including the big three in Singapore, puts thousands of subscribers behind a shared pool of public IPs. Your device gets a private address on the carrier’s internal network, and NAT translation happens somewhere in their core. NAT tables have finite memory, so idle entries get evicted, typically well under the timeouts you’d see on a home router.
• Cell handoffs. As a phone or modem moves between towers, or even just re-selects a stronger cell on the same tower, the radio bearer gets renegotiated. Sometimes this is seamless at the IP layer. Sometimes the device gets a new PDP context (the mobile data equivalent of a DHCP lease), and your IP changes mid-session.
• Radio power states. Modems don’t stay in a high-power “connected” radio state indefinitely. After a period without traffic, the baseband drops from a full-power RRC connected state down to idle to save battery. Waking back up to send a packet takes time and can be the thing that finally kills a connection sitting right at the edge of a NAT timeout.
• APN and session renewal. Carriers periodically re-authenticate and renew the data session at the APN level. Most of the time this is invisible. Occasionally it’s not, and whatever socket you had open doesn’t survive it.

None of this is carrier incompetence. It’s the tradeoff a network makes when it has to serve millions of battery-powered devices instead of a rack of servers with a guaranteed power and Ethernet connection.

What “dead” actually looks like

The frustrating part is that a dropped mobile connection usually doesn’t send a clean TCP RST or FIN. The NAT entry on the carrier side just disappears. Your local socket still thinks it’s connected because nothing told it otherwise. You only find out when you try to write to the socket and get nothing back, or your read call hangs until whatever timeout you configured (or didn’t configure) finally fires.

This is why jobs that use short-lived HTTP requests generally cope fine on mobile lines and jobs that hold a session open, a WebSocket, a long poll, an SSE stream, a persistent scraping session with cookies tied to a TCP connection, are the ones that fall over.

TCP keepalive helps, but it’s not enough on its own

The operating system’s built-in TCP keepalive sends an empty ACK after a period of inactivity to confirm the peer is still there. The default intervals on most OSes (often two hours before the first probe) are far too long to matter here. You want something closer to a probe every 30 to 60 seconds if you’re relying on OS-level keepalive on a mobile link, tuned with SO_KEEPALIVE plus the idle, interval, and count parameters your platform exposes.

Two problems with leaning on this alone:

1. It only tells you the connection died. It doesn’t prevent the NAT entry from expiring, and on some networks the keepalive probe itself is what gets silently dropped without a response, so you still end up waiting on a timeout to notice.
2. Some middleboxes and carrier NAT implementations don’t treat a bare ACK as “real” traffic for the purpose of resetting the idle timer. Behavior here varies by carrier and isn’t something you can rely on being consistent.

Application-level heartbeats do the actual work

If the protocol supports it, sending real payload traffic, not just a TCP-layer ACK, on a fixed short interval is what actually resets the NAT idle timer reliably. WebSocket ping/pong frames are the standard example: send a ping every 15 to 30 seconds, expect a pong back, and treat a missed pong as a dead connection you need to replace, not wait out.

For plain HTTP-based long polling, this means keeping the poll interval well under whatever the shortest NAT timeout you’ve observed is, rather than trusting a generous timeout and hoping it holds. For scraping frameworks that reuse a session across many requests, it means either issuing a lightweight request often enough to keep the underlying connection warm, or accepting that the connection will eventually die and building reconnect logic that re-authenticates cleanly rather than assuming the cookie jar and TCP state survive together.

Design for reconnection, not for uptime

The mistake we see most often is treating a mobile-backed connection like a fixed-line one and writing code that assumes a session, once established, stays established. On a mobile line, the healthier assumption is the opposite: any long-lived connection will eventually drop, sometimes because of NAT eviction, sometimes because of a handoff, sometimes because the carrier renewed the session underneath you. The job of your code is to notice quickly and recover cleanly.

Practically, that means:

• Detect failure fast with short heartbeats instead of relying on a long read timeout to eventually give up.
• Keep reconnection logic idempotent. Re-authenticating or re-establishing a WebSocket should be cheap and safe to do repeatedly.
• Don’t tie irreplaceable state to a single TCP connection. If your scraping session’s cookies or tokens are still valid after a reconnect, the drop costs you a few seconds. If they’re not, you’ve lost the whole session and have to start over.
• Log the reconnects. If you’re seeing drops every few minutes on one SIM and every few hours on another, that’s a real signal about how that carrier’s NAT and radio behavior differs, and it’s worth tracking per line rather than averaging across your whole fleet.

Where IP rotation and connection stability pull in opposite directions

Worth being upfront about a real tension here: a lot of what makes mobile lines useful for scraping and multi-account work, the fact that your IP can change on handoff or session renewal, is the same mechanism that breaks long-lived sessions. You can’t fully have both a connection that never drops and an IP that rotates on its own schedule. If a workload genuinely needs both a stable long session and a mobile-attributed IP, the honest answer is to build the reconnect-and-reauth path well rather than to look for a setting that makes the underlying radio behavior go away. It won’t.

On our own farm this is exactly why we treat each modem’s connection as something that gets watched and re-established, not something we assume will stay up. Real SIMs on real carriers behave the way the network wants them to, not the way your code hopes they will.

The short version

Long-lived connections drop on mobile lines because of CGNAT idle eviction, cell handoffs, radio power-state transitions, and periodic session renewal, not because of anything wrong with your code. OS-level TCP keepalive is too coarse to fix this by itself. Application-level heartbeats sent often enough to beat the shortest NAT timeout you’ve seen, paired with fast failure detection and cheap reconnection logic, is what actually keeps automation and scraping jobs running over mobile carriers for hours instead of minutes.

If you’re building on real Singapore mobile IPs and want to talk through how a specific workload holds up on carrier connections, come find us here.

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