What Are Backconnect Proxies? One Gateway, Many Exits

"Backconnect" is a vendor word for an architecture, not a protocol you will find in an RFC. A backconnect proxy gives you a single, stable entry point, one hostname and port, that you put into your client once and never change. Behind that entry point the provider operates a pool of exit addresses, and the connection your destination actually sees comes from one of them. The name captures the inversion: instead of you connecting out to a specific proxy IP, you connect to a gateway that connects back out through whichever exit it selects.

This is why the same service is marketed as a "rotating proxy," a "proxy gateway," or a "backconnect network": those are three names for the same delivery model. The word tells you how addresses are delivered (through a gateway, from a pool) and nothing about protocol, network origin, or legitimacy. A backconnect gateway can front residential, datacenter, ISP, or mobile exits; those describe where the exits live, while backconnect describes how you reach them.

The rest of this guide takes that architecture apart on a gateway small enough to read, because the mechanism is easier to trust when you have watched one address turn into several.

This gateway binds only to loopback and relays to a lab origin you also run. It sends each request out through a different local source address using the Node.js socket localAddress option, which is the smallest honest stand-in for "egress through a different network address." It uses absolute-form request targets exactly as a real HTTP proxy does. Save it as backconnect-lab.mjs; it was verified with Node v24.14.0.

// backconnect-lab.mjs: one gateway address, two exits behind it.
// Loopback only. Point it at nothing except the lab origin.
import http from 'node:http';

const EXITS = ['127.0.0.2', '127.0.0.3'];
let turn = 0;

http.createServer((request, response) => {
  console.log(`[origin] ${request.url} from ${request.socket.remoteAddress}`);
  response.end('ok\n');
}).listen(8091, '127.0.0.1');

http.createServer((request, response) => {
  let target;
  try { target = new URL(request.url); } catch {
    response.statusCode = 400;
    return response.end('absolute-form target required\n');
  }
  if (target.hostname !== '127.0.0.1' || target.port !== '8091') {
    response.statusCode = 403;
    return response.end('lab gateway relays to the lab origin only\n');
  }
  const exit = EXITS[turn++ % EXITS.length];
  http.get({ host: target.hostname, port: target.port, path: target.pathname, localAddress: exit }, (upstream) => {
    response.writeHead(upstream.statusCode ?? 502);
    upstream.pipe(response);
  }).once('error', () => { response.statusCode = 502; response.end('exit failed\n'); });
}).listen(8090, '127.0.0.1', () => console.log('gateway on 127.0.0.1:8090'));

Start it with node backconnect-lab.mjs, then send four requests to the same gateway address and watch the origin's log:

for i in 1 2 3 4; do curl -s -x http://127.0.0.1:8090 http://127.0.0.1:8091/request-$i; done

The client configuration (-x http://127.0.0.1:8090) is identical on every call, yet the origin recorded four connections from two alternating addresses:

[origin] /request-1 from 127.0.0.2
[origin] /request-2 from 127.0.0.3
[origin] /request-3 from 127.0.0.2
[origin] /request-4 from 127.0.0.3

That is the whole trick. One gateway, a pool behind it, rotation on the provider's side. The committed verification harness extends this to three exits and adds the sticky-session behavior described next; its recorded run is in the evidence file linked from this article's brief.

A gateway that rotated on every single request would be unusable for any task that needs continuity: a multi-step form, a paginated result set, a login that sets a cookie. So backconnect providers expose rotation policy as a parameter, and the near-universal convention is to encode it in the proxy username rather than in a separate setting. You authenticate to the gateway with Proxy-Authorization, and the username carries session and geo instructions the gateway parses.

In the verification harness a username containing session-abc123 pinned three consecutive requests to a single exit, while a different token, session-zz9, mapped to a different one. Requests with no session token rotated per request. The exact grammar differs by provider (some use sticky-, some append a TTL, some take a country code), but the shape is consistent:

# Rotate every request: no session token
curl -x http://user:pass@gateway.example:7000 https://example.com/

# Sticky: the same session id reuses one exit until it expires
curl -x http://user-session-abc123:pass@gateway.example:7000 https://example.com/

Two consequences follow. First, "sticky" is not permanent: a pinned exit is held for a provider-defined window or until it fails, then the session moves. Second, session identifiers are your control surface for continuity and your responsibility for isolation, one identifier per logical workflow, never shared across jobs that must not correlate. The static versus rotating guide works through the session-design decisions this exposes: how long to hold a session, when to rotate deliberately, and how retry policy interacts with a moving exit.

Because backconnect describes only the delivery model, most of the questions that decide whether a service fits your job are left unanswered by the label, and a pool that hides its own size can hide its own quality. Judge the network, not the architecture.

Two clarifications kill the most common confusions. A backconnect gateway does not make traffic anonymous: the destination still observes cookies, accounts, TLS behavior, and everything catalogued in the proxy fundamentals guide, and a rotating source address changes none of it. And rotation is not a way around a control: if a destination returns a 403, 429, CAPTCHA, or account restriction, a fresh exit is a signal to stop and check authorization, not a lever to pull. A proxy changes the route, never the permission.

Two checks separate a working backconnect service from a marketing claim, and both use tools you already have. First, confirm rotation is real: send several requests with no session token and read back the exit each time. Second, confirm stickiness holds: send several with one session token and confirm the exit stays put. Use an endpoint you are authorized to hit that echoes the source address, such as Databay's own IP echo.

# Does the gateway rotate? Expect different values.
for i in 1 2 3; do \
  curl -s -x http://USER:PASS@GATEWAY:PORT \
    https://databay.com/what-is-my-ip/json; done

# Does a session stick? Expect one repeated value.
for i in 1 2 3; do \
  curl -s -x http://USER-session-test01:PASS@GATEWAY:PORT \
    https://databay.com/what-is-my-ip/json; done

Record the observed exits, the session grammar the provider documents, and whether protocol support (HTTP, CONNECT for HTTPS, SOCKS5) matches what you configured. For a point-in-time liveness and header read on any single exit, the proxy checker is the companion diagnostic; it inspects one connection rather than proving pool behavior, so run it alongside these loops, not instead of them.

When the requirement is a maintained gateway with a documented session grammar and named accountability for how the pool is sourced, that is what managed residential and datacenter networks provide. Backconnect is the shape of the service; the quality is in the exits behind it and the operator who stands behind those.