What is a backconnect proxy?

Short answers

How a backconnect gateway works

With a traditional proxy list, each host:port entry is a separate server with its own exit address, and your code decides which entry to use. A backconnect service turns that around. You configure one endpoint, and the selection of an exit happens on the gateway, according to the settings you send with the connection.

1. Your client opens a connection to the gateway host and port, over HTTP CONNECT or SOCKS5.
2. The gateway authenticates the username and password and reads the options carried in the username.
3. It selects an exit device from the matching pool, or reuses the one bound to your session name.
4. Your traffic leaves through that device. The destination sees the device’s public address.

A proxy list and a backconnect gateway are both forward proxies: your client chooses to send its requests through them. A reverse proxy is the opposite arrangement, run by a website in front of its own servers; the forward vs reverse proxy guide compares the two.

Mobile and peer devices usually sit behind NAT, and mobile carriers commonly use carrier-grade NAT. A device behind NAT can still keep an outbound connection open to the network, which is how the gateway reaches it. The CGNAT guide explains why carrier addresses are shared and why an exit address can change while the device stays the same.

Rotating and sticky sessions

Per-connection rotation does not mean per request. Browsers and HTTP libraries keep connections open and reuse them, so several requests can share one exit. If your job needs separate exits, open separate connections, and test the behaviour with the client that will run the job.

A sticky session prefers an existing binding without reserving a device. The carrier may still change the IP of that device. A session can also end when its device goes offline, so a sticky job needs a recovery step. The rotating vs sticky guide explains how to choose a mode and what each one guarantees.

One credential: pool, country and session in the username

Portproof works as a backconnect gateway. Every customer has one gateway username base and one proxy password. The full username adds the settings for the connection, so the same credential serves both pools, every available country and every rotation mode. Copy complete usernames from the connection builder; the setup docs list every token.

ACCOUNT-<pool>-<country>-sid-<saved_id>-rot-<mode>

pool     mbl (mobile 4G/5G) · peer (residential peer network) · best
country  two-letter lower-case code, or any
sid      saved session identifier, needed for timed and sticky modes
rot      ondemand · auto5 · auto10 · auto20 · auto60 · sticky

http://<username>:<password>@gw.portproof.org:7000
socks5h://<username>:<password>@gw.portproof.org:7001

The peer pool is the residential product: opt-in peer devices in a mixed network, so it does not enforce residential-only addresses. Optional tokens such as carrier, city, state, ASN and IP type narrow the selection further. A combination that matches no online device is refused with an error rather than silently widened, and a country with nothing online returns E_NO_STOCK_COUNTRY.

Choose a pool for the network your work needs: mobile proxies exit through carrier modems, residential proxies through opt-in peer devices. Both are shared pools on one GB balance; neither reserves an address for you. How the username is placed inside a proxy URL, and how to encode it, is covered in the proxy format guide.

Check the rotation you configured

for i in 1 2; do
  curl --disable --silent --show-error --noproxy '' --connect-timeout 5 --max-time 15 \
    -x "http://gw.portproof.org:7000" --proxy-user "USERNAME-peer-nl-rot-ondemand" \
    https://api.portproof.org/v1/echo-ip
  echo
done

# example
#   203.0.113.x
#   198.51.100.x

Two separate curl runs open two connections, so each gets its own selection. Equal addresses are possible and do not prove that rotation failed. The curl guide shows the same checks for sticky sessions and explains what a check costs in traffic.

When a backconnect proxy fits

• Price monitoring and market research that read many public pages and do not need one fixed route.
• Ad verification and QA checks that must see a page from a chosen country or network type.
• Data pipelines and AI agents that prefer one endpoint and credential over managing a server list.
• Multi-step QA journeys that need a sticky session for their duration, with a recovery step if it ends.

A backconnect gateway is the wrong tool when a job needs one address that never changes, such as an allow-list entry on a partner system. Shared pools do not provide that. Measure a representative run against the account meter before scaling, and size the balance with the GB planning guide.

What is not allowed

Use the gateway for lawful work such as price monitoring, ad verification, market research and QA, within each site’s terms. Account farming, credential stuffing and ignoring a site’s rate limits are refused. See the acceptable-use policy.

Read next