Backconnect proxies: one line with a whole pool behind it
How backconnect proxies work: gateway, exit pool, rotation and sessions. What to check before buying, where the format wins and what its limits are.

When a service says "millions of addresses in the pool" and gives you one connection line, the backconnect scheme is at work. Understanding its mechanics removes half of the questions people bring to support: why the address changes by itself, where those millions live and what a session means. Let's go through the scheme from the start to the checks before buying.
The scheme: gateway and pool
A line of the form host:port:login:password points to the gateway: a permanent server with a permanent name. All your traffic arrives there, and then the gateway sends each request out through one of the pool's exit addresses. The exits are devices that match the pool type: home connections for residential plans, cellular networks for mobile, server addresses for data center. You configure the software once and it knows nothing about address changes: all the mechanics live on the service's side.
Rotation and session
There are two exit modes, and you choose them when creating the list or through parameters in the line. Rotation: a new address on each request, the natural mode for scraping and checks where each request stands alone. Session: the gateway fixes an exit to your line. On Resi Core and Resi Prime you set the term from 3 minutes to 24 hours. Either way a device can leave the network sooner. Everything account-related needs sessions: login, work, logout from one address. A third option, refreshing the list on a schedule, turns a set of session lines into slow rotation: addresses change every N minutes as a whole list.
Where the format wins
- Scale without administration. Thousands of exits through one software setting: parallel scraping, price monitoring and checkers grow with no config edits.
- A living pool. The service removes dead exits from the pool itself, so you never clean lists: the gateway simply will not issue a dead address.
- Location on demand. The country, and on higher plans the city and carrier, are set in the line: one gateway serves all pool regions, as we showed clearly in the German pool measurements.
Limits worth knowing
An exit does not belong to you personally: in a rotating pool, clients share addresses over time, and a specific IP's reputation holds other people's history. For scraping this does not matter, while long-lived accounts call for long sessions and cleaner pools. Session lifetime is not infinite: a home device can go offline and the exit changes early, so your software must survive that. And latency: the path through the gateway plus the last mile of a home exit gives a response noticeably slower than a server's, as the measurements in the article above honestly show.
| Question before buying | Why |
|---|---|
| What modes: rotation, session, their limits | whether the format fits your task |
| How location is set and how accurate it is | the country in the line must pass a check |
| What about HTTP and SOCKS5 | compatibility with your software |
| How billing works: traffic or term | the economics of the task |
| Is there a small test | a check before the budget |
Billing for this format almost always goes by traffic: you pay for gigabytes passing through the gateway, and the number of exits does not matter. A practical consequence: you save by cutting extra traffic, from disabling images in the scraper to sensible retries, and hunting for a cheap gigabyte gives less. The second consequence is nicer: the number of lines and threads does not limit the budget, so you can generate lists for each subtask freely.
Where the exits come from
An honest question for any pool: on what terms did the devices get there. With decent services, exits come from partner apps, where the device owner knowingly shares the channel for a reward, and from the service's own infrastructure. Gray pools on infected devices also exist: the price is lower, the legal and moral risks are higher, and such a pool is unstable by nature. Indirect signs of cleanliness: the service explains where addresses come from, pools do not overlap between products, and support answers questions about the source with no fog.
How to check backconnect in ten minutes
Take a test volume and run four checks. Rotation: several requests in a row to the IP lookup page must exit from different addresses. Session: the same series on a session line holds one address. Location: the country in the response matches the one set in the line. Exit type: the ASN lookup shows a home provider for residential and hosting for data center, so any swap shows instantly. A full list of lines is easier to run through the checker: status, protocol and response for each line in one pass. These ten minutes answer questions more honestly than any plan description, ours included, and that is why we advise starting your acquaintance with the format here.
Read next

Cheap proxies: what the lowest-price buyer really risks
A proxy's price consists of the pool, the channel and support, and when it sits many times below market, someone saved on one of these. We cover five typical risks of cheap offers, from addresses…
5 min read
German Proxies in Numbers: Resi Core and Resi Prime Pools
We ran the Resi Core and Resi Prime pools with a Germany filter: 13,210 and 8,631 unique addresses through one line, 114 and 88 autonomous systems in the samples, 370 and 322 cities per thousand IPs…
14 min read
Proxies for IAM: how to pick lines and enter them correctly
IAM can handle hundreds of accounts, but without the right proxies this ability is useless: the platform looks at each profile's address. We cover which lines suit InstAccountsManager, how to tie an…
5 min read