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.
Session Stickiness: Ports and Time Windows
Sticky sessions are usually implemented in one of two ways on a backconnect gateway: a dedicated port range where each port maps to a pinned backend for the session's lifetime, or a session identifier appended to the proxy username that the gateway reads to route consistently. PXM2's gateway uses the port-based approach — request a sticky port and every connection through it lands on the same backend IP until the session window closes, typically for a duration you set between one and sixty minutes.
When a sticky window expires, the gateway does not warn you — the next request on that same port simply lands on a new backend IP, silently, the same way an ordinary backconnect request would if you had not asked for stickiness at all. Any workflow that logs in, adds items to a cart, and checks out needs to either keep its sticky window longer than the whole workflow takes, or re-authenticate if the window lapses mid-flow.
Authentication and Protocol Support
A backconnect gateway accepts either of two authentication methods: IP whitelisting, where the gateway checks the source address of the connecting client against a list you maintain, or username and password credentials sent with each request, which work from any network without needing to register an IP first. Credential auth is the practical default for CI runners, cloud functions, and any environment where the outbound IP changes between runs. On protocol support, the gateway speaks HTTP with CONNECT tunnelling for HTTPS targets, and SOCKS5 for tools that route non-HTTP traffic through the same proxy; TLS between your client and the destination server passes through the gateway unmodified in both cases, so certificate validation on the target site is unaffected by the proxy hop.
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.
What Changes in Your Code, and What Doesn't
Pointing an existing tool at a backconnect gateway is usually a one-line change: set the proxy field in a browser-automation framework, an HTTP client library, or a plain curl command to the gateway's host and port, the same as you would for any other HTTP proxy. What does not appear anywhere in that configuration is a list of backend IPs, a health-check routine to skip dead ones, or a refresh job to pull an updated list on a schedule — all of that lives on PXM2's side of the gateway, not in your script. If you later change the rotation frequency or move to a different country pool, the gateway address in your configuration does not change at all.
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.
The same logic extends to ad-verification tools, SERP rank trackers, and no-code automation platforms that expose a single proxy field in their settings screen rather than an API for managing a rotating IP list. Anywhere the tool's interface assumes exactly one upstream proxy, backconnect is the connection type that matches what the tool expects, while a direct rotating proxy would require code you would otherwise have to write yourself to sit between the tool and the pool.
What Backconnect Removes From Your Code
Managing a rotating pool of direct addresses yourself means writing retry logic for backend IPs that go stale mid-session, a scheduled job to re-fetch the current address list, and a health check to route around whichever entries are temporarily down. A backconnect gateway absorbs all three: a request that would have hit a dead backend is retried against a live one before it ever reaches your client, so a failed connection at the gateway is rare enough that most integrations do not build their own retry wrapper around it at all.
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.
Where This Actually Bites
The clearest failure case is a payment processor's sandbox or production allowlist, where the provider lets you register a fixed set of source IPs and rejects everything else. Point that kind of integration at a backconnect gateway and it works right up until the hidden backend rotates, at which point every call starts failing with no code change on your end to explain why. The same applies to a VPN or firewall rule scoped to one IP, or a compliance sign-off that names a specific address in writing.
None of this rules out combining both connection types in the same project — running bulk scraping traffic through a backconnect gateway and routing only the allowlist-sensitive call through a dedicated proxy, so a fixed IP is paid for on the one leg that actually needs it.
| 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
Poland
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