Backconnect Mobile Proxies
A backconnect mobile proxy gives you one stable gateway address to connect to, while the carrier-assigned backend IP behind it rotates transparently — an architecture choice, not a rotation policy, built so your client never has to reconfigure proxy settings when the backend changes.
- One gateway address, a rotating backend — you connect to a single stable IP:port; the carrier-assigned backend IP behind it changes without you touching your proxy settings.
- Architecture, not rotation policy — how often the backend changes is a separate question from the fact that you never see or reconfigure it directly.
- Session-sticky by convention — a cookie or header can pin your session to one backend IP for a set number of minutes even though the gateway address itself never moves.
- The wrong choice for IP allowlisting — a firewall rule keyed to one address breaks the moment the hidden backend rotates underneath it.
Point your client at one gateway once — the backend IP changes behind it without touching your proxy settings.
Pin a session to one backend IP for a set number of minutes using a cookie or header.
How Backconnect Mobile Proxies Route Behind One Gateway
A backconnect mobile proxy is defined by its architecture, not by any rotation policy. Your client connects to one stable gateway IP:port, and that address never changes. Behind it, the actual carrier-assigned backend IP rotates transparently — the gateway routes each outbound request through whichever backend is currently live, without your client ever needing to know or care which one that is.
Because the client only ever sees the gateway, there is nothing to reconfigure when the backend changes. A scraping script, a browser-automation framework, or a whitelisted proxy setting in a third-party tool keeps pointing at the same address indefinitely, regardless of how often the carrier IP behind it turns over.
Backconnect setups are commonly paired with session-stickiness — a cookie or header the gateway recognises to pin a "session" to one specific backend IP for a set number of minutes, even though the gateway address itself never moves either way.
Backconnect vs Rotating: Topology vs Rotation Policy
It is easy to conflate backconnect with rotating mobile proxies, but they answer different questions. Rotation policy is about frequency and trigger — per request, on a timer, every few minutes or hours. Backconnect is about topology — whether you connect to one gateway address that hides a pool, or manage the pool's addresses directly yourself. A proxy can be rotating and backconnect at the same time; the two properties do not compete, and PXM2's backconnect gateways rotate their hidden backend on a comparable schedule to a standalone rotating proxy.
The direct-attached alternative — connecting straight to the backend address, no gateway in between — is the pattern dedicated mobile proxies use instead, since a dedicated proxy has nothing hidden behind it to route through in the first place.
When Backconnect Fits Your Integration
Backconnect earns its keep whenever your tooling cannot easily handle reconfiguring a rotating list of proxy addresses. Browser-automation and scraping frameworks are the clearest case: point the framework's proxy setting at one gateway address once, and the backend rotation happens entirely on PXM2's side from then on — no list to fetch, parse, or refresh in your own code.
When You Need a Fixed, Auditable IP Instead
Backconnect actively works against a job that needs a guaranteed, auditable, unchanging IP — the case for IP allowlisting or compliance sign-off. A firewall rule keyed to one specific address is written against whatever backend happened to be live when you wrote it, and breaks the moment backconnect silently rotates that backend behind the unchanged gateway.
For that requirement, dedicated mobile proxies are the connection type built for it: one SIM and one IP reserved for you, with nothing hidden behind a gateway to rotate out from under an allowlist entry.
| Property | Backconnect | Rotating (direct) |
|---|---|---|
| What the client connects to | One fixed gateway address | The current backend address directly |
| Reconfiguring on rotation | None — the gateway address is stable | Needed if you manage the list yourself |
| Cost / performance | Comparable price, simpler integration | Comparable price, more list management |
| Best for | Frameworks that want one endpoint | Tooling that already manages proxy lists |
The rotation behaviour underneath is similar either way — the real trade-off is how much proxy-list management you want to own yourself versus hand to the gateway.
Get a Backconnect Mobile Proxy
Live PXM2 locations — every gateway below points at a rotating pool of carrier-assigned backend IPs:
France
India
Singapore
Frequently Asked Questions
What actually changes when a backconnect proxy “rotates”?
The gateway address you connect to never changes — the carrier assigned IP behind that gateway does. Your client keeps talking to the same IP:port throughout, and the backend swap happens on the provider’s side, so there is nothing in your proxy configuration to update when it happens.
How is backconnect different from a rotating mobile proxy?
They sit on different axes. Rotating mobile proxies describe a rotation policy — how often or on what trigger the IP changes. Backconnect describes a topology — one gateway address hiding a pool, regardless of how often the hidden backend changes. A proxy can be both rotating and backconnect at the same time; the two questions do not conflict.
When should I use backconnect instead of a rotating proxy list?
When your tooling cannot easily handle reconfiguring a rotating list of proxy addresses. Browser-automation and scraping frameworks are the common case — point one gateway address at the framework once, and forget it, instead of managing a list that changes underneath your configuration.
When does backconnect fail me?
When you need a guaranteed, auditable, unchanging IP — for allowlisting or compliance. A firewall rule keyed to one specific address breaks the moment backconnect silently rotates the backend behind it. Dedicated mobile proxies are the connection type built for that instead: one SIM, one IP, held for you rather than hidden behind a gateway.
Does session stickiness mean the IP never changes?
No — sticky sessions only pin your traffic to one backend IP for a set window, typically a few minutes, using a cookie or header the gateway recognises. Once that window ends, or you start a new session, the gateway can hand you a different backend IP again. The gateway address itself still never changes either way.
Related Mobile Proxy Guides
Proxy types
Core mobile proxy guides
Get a Backconnect Mobile Proxy
One gateway address, dedicated 4G/5G modems behind it, unlimited bandwidth, and optional sticky sessions when a task needs to hold one backend for a while.
Get a Mobile Proxy