The core issue: the IP stays, but the connection dies
In mobile internet (and especially in mobile proxy setups) two things are often mixed up: keeping the same public IP and keeping the same transport connection. A “sticky IP” typically means the operator keeps your public IP (or the same NAT egress pool) for some time. It does not guarantee that a long‑lived TCP/QUIC connection will never drop.
The most common reason for “drops without an IP change” is handover—moving the device from one cell/site to another—and the chain of mobility procedures around it: radio resource switching, context transfer, and user‑plane path switching. A short interruption and packet loss during this window can be enough for the client, proxy, load balancer, or server to time out and close the socket.
What handover is (plain language)
Handover is the network procedure that keeps you connected while you move or while radio conditions change. In LTE (4G) the base station is an eNodeB; in 5G it is a gNodeB. Handover can happen:
- inside a node (sector/frequency change),
- between sites/cells (inter‑eNB / inter‑gNB),
- across technologies (4G↔5G, etc.).
In LTE you will often see X2 and S1 handover terminology. Operationally, the point is simple: the radio anchor changes and the core network updates the user‑plane route to the new cell. The public IP can remain the same because it is usually tied to the core session (PDN/PDU session), not to a specific cell site.
In 5G SA (Standalone), continuity is explicitly defined via Session and Service Continuity (SSC) modes, which describe whether attachment parameters (including IP) are preserved across mobility and user‑plane relocation.
Why a “sticky session” can break even when the IP does not change
1) Brief interruption + loss triggers timeouts
LTE/5G handovers can cause short user‑plane interruption: while the network transfers context and switches routes/tunnels, packets may be delayed or lost. Browsing hides this with quick retries, but long‑lived connections (WebSocket streams, API streaming, remote control, long TLS sessions) are much more sensitive.
2) Path switch in the core interacts with stateful middleboxes
During inter‑cell mobility the core performs a path switch so user traffic is delivered through the target cell. In practice, buffering, queues, and occasional gaps can push a proxy/LB/server over its timeout thresholds.
CGNAT adds another layer: even with the same public IP, the operator may change NAT mappings (e.g., the source port). Systems that bind “session state” to the 5‑tuple can treat this as a new session.
3) Handover failure or RLF (radio link failure)
Not every handover succeeds. If radio quality degrades, interference rises, or the device “ping‑pongs” between cells, the network can hit handover failure or radio link failure (RLF). Then the device re-establishes connectivity via new procedures, and applications see a hard drop even if the public IP later ends up unchanged.
4) 4G↔5G (NSA/SA) and dual connectivity add moving parts
In 5G NSA, 5G radio is often anchored to LTE, so mobility may involve both LTE handover and NR context changes, increasing interruption risk. In 5G SA mobility is simpler on the radio side, but SSC modes and user‑plane relocation still matter.
5) “Sticky” in proxies is often tied to connections/time, not just IP
Many proxy implementations enforce stickiness as “keep the same upstream for N minutes” or “pin the user to one modem.” If the TCP socket dies, a new socket can come with a new port/path/state—even with the same IP. It helps to separate:
- sticky IP (addressing/core/NAT attachment),
- sticky session (survivability of a particular transport flow).
How to confirm it is handover‑related
- Public IP before/after is the same, but logs show timeouts/RST/reconnect.
- A short ping gap or packet loss spike at the same timestamp.
- Radio identifiers/metrics change (cell ID/PCI, band, SINR/RSRP).
- No long “offline” period (10–60 s), yet sockets drop.
What mobile proxy providers can do
- Harden connections: enable TCP keepalive; add heartbeat for WebSockets; avoid overly aggressive timeouts.
- Don’t bind stickiness only to a single socket: pin users to a modem/route so a reconnect lands on the same upstream.
- Make reconnect cheap: rely on auth/session tokens rather than IP:port; implement retries with backoff; store progress for crawlers.
- Monitor mobility: correlate drops with radio metrics (RSRP/RSRQ/SINR, cell IDs) to distinguish handover interruption from RLF or actual detach/attach events.
What users can do
- Don’t use ultra‑short timeouts on mobile links; allow for brief gaps.
- Send lightweight keep‑alives every 20–40 seconds to keep NAT state alive.
- Use clients with solid retry logic and idempotent request patterns.
- For very long sessions, consider a tunnel (WireGuard/VPN) with auto‑reconnect: it won’t remove handovers, but it can hide reconnection complexity.
Myth: “If the IP doesn’t change, nothing changed in the network”
In 4G/5G, the IP is only the top layer. Below it are user‑plane tunnels and multiple stateful nodes. Mobility can change tunnel endpoints and routes, while NAT/LB timers can kill a flow even with the same IP.
Conclusion
A sticky IP in mobile internet is not the same as an unbreakable sticky session. Handover can introduce short interruption or even RLF, which is enough to drop TCP/QUIC connections without changing the public IP. Real stability comes from engineering: reasonable timeouts, keepalives, routing/modem pinning, and reliable reconnect behavior.