“Backconnect” is one of those terms that appears in proxy documentation without ever being defined, usually because the people writing it have forgotten it was ever unfamiliar. It describes an architecture, and once you see the architecture the rest of the product makes sense: why there is only one address to configure, why your targeting lives in a username, and why your HTTP client can quietly break rotation without anything appearing to be wrong.
Where the name comes from
The older model was a list. You bought a set of proxies and received a file of addresses and ports, and your code connected directly to each one. Managing them was your problem: which are alive, which are blocked on which target, how to spread load across them, what to do when the list changed.
Backconnect inverts that. You connect to a single gateway address, and the gateway connects back out through one of the many nodes in its network on your behalf. You never learn the exit address in advance and you never manage a list, because the routing decision happens on the provider’s side at the moment of the request. That is the whole idea: one stable front door, many rotating back doors.
In practice “backconnect proxy”, “rotating proxy” and “gateway proxy” are used more or less interchangeably today, with backconnect emphasising the architecture and rotation emphasising the behaviour it produces.
What happens on a single request
Concretely, when your client sends a request through a backconnect gateway:
- Your client opens a connection to the gateway,
p.shifter.io:443, and authenticates with a username and password. - The gateway parses your username, which carries more than identity. Any targeting flags for country, region, city or ASN, and any session identifier and TTL, are encoded there.
- It selects an exit node matching those constraints from the currently available pool. Available is the operative word, since the pool is a population that turns over continuously, as covered in how providers build and refresh pools.
- It forwards your request through that node, so the target sees the node’s residential address rather than yours or the gateway’s.
- The response comes back the same way.
If you supplied a session identifier, the gateway remembers the mapping and routes subsequent requests bearing that identifier through the same node until the TTL expires or the node drops. If you did not, the next request gets an independently selected exit.
That is why targeting lives in the username. There is only one endpoint, so per-request instructions have to travel in the only per-request field the proxy protocol gives you before the tunnel is established.
# same host and port, different behaviour, expressed entirely in the username
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-de-sid-abc123-ttl-600:PASSWORD@p.shifter.io:443 https://ipinfo.io/jsonWhat this changes in your code
Three practical consequences follow from the architecture, and the first one causes more confusion than anything else in this product.
Rotation happens per connection, not per request. The exit is chosen when the tunnel to the gateway is established. Modern HTTP clients keep connections alive and reuse them, so if your client sends ten requests down one pooled connection, all ten leave through the same exit, and it looks exactly like rotation is broken. It is not: your client is doing what it was designed to do. The fix and the diagnosis are in IP not rotating, and the short version is that a curl loop in separate processes will rotate while a shared session object will not.
There is no IP list to manage, and no IP to blame. Health is a property of a route, meaning target plus geography, and of a session, rather than of an address you could add to a deny list. That reframes monitoring and failure handling entirely, per monitoring proxy health at scale.
Configuration is static, behaviour is dynamic. The host and port never change, so switching a job from rotating US exits to sticky German ones is a string change rather than a redeployment. That is what makes multi-market collection a configuration matter instead of an infrastructure project.
Backconnect versus the port-list model
The older model still exists, and the comparison is useful because it explains why the industry moved.
With a port list you knew your addresses, which sounds like an advantage and mostly is not: you inherited the work of liveness checking, load spreading and replacement, and your capacity was a fixed count of ports rather than something that flexed with demand. Pricing followed the same shape, per port rather than per unit of work, which is the model discussed in why the per-port era is over.
With backconnect you give up knowing the exit in advance and gain not having to manage one. Capacity becomes a question of bandwidth and concurrency rather than of how many ports you bought, and rotation is a parameter rather than an implementation you write yourself.
Where the older shape still wins is when you genuinely need the same address to persist, which is what static ISP proxies exist for, per ISP versus residential.
Sticky sessions inside a backconnect gateway
Sticky sessions are worth understanding as what they are: a mapping the gateway holds, not an allocation you own.
You choose an identifier, the gateway associates it with an exit node, and requests carrying that identifier follow the same route until the TTL runs out. Because the node is a real household device, it can also disappear before the TTL does, which is why a sticky session is best effort rather than a lease. Code that treats a mid-sequence address change as an error rather than a normal event will be flaky for reasons that have nothing to do with the provider. The behaviour is covered in sticky versus rotating and the underlying churn in how rotation works.
The bottom line
Backconnect means you connect to one endpoint and it connects back out through many, choosing the exit per request from whatever is currently available. That architecture is why there is a single host and port, why country, city, session and TTL are encoded in the username, and why you never manage an address list. It also explains the most common source of confusion in this product: rotation is decided when a connection is established, so an HTTP client reusing a pooled connection will send every request through the same exit and look like it is failing to rotate. Treat exits as ephemeral, sessions as a mapping rather than an allocation, and health as a property of routes, and the architecture stops surprising you.
That gateway is the whole interface to residential proxies: one host, one credential pair, with rotation, geography and session behaviour expressed per request and billed per GB rather than per port. If you are new to the terminology, the glossary covers the rest of it.