What is a backconnect proxy and how does it work?

With a classic proxy list you receive, say, 100 IP addresses and your software spreads requests across them. You track which ones are blocked, replace dead ones and write the rotation logic yourself. A backconnect proxy turns that around. You receive a gateway address, the gateway holds the pool, and it connects “back” out to the internet through whichever IP it assigns to your connection.

The term is used loosely. Some providers call any rotating residential product backconnect; others mean the gateway architecture in general. Here it means the architecture: one stable entry point, many changing exit IPs. Storm Proxies delivers its rotating product this way, which is why our gateways are listed as fixed IP:PORTs that never change.

Where people get stuck is the rotation itself: their IP doesn’t change when they expect it to, or it changes in the middle of a login. This page explains how a gateway decides, how per-request and timed rotation differ, and how to pick the right gateway for each job.

Both approaches end with requests leaving from many IPs. The difference is who does the work.

• Configuration. A list means pasting hundreds of lines into every tool and updating them when IPs are replaced. A gateway is one line, or a few if your plan includes several gateway ports, and it stays the same for the life of the account.
• Rotation logic. With a list, your code chooses the next IP, retires blocked ones and balances load. With a gateway, the pool is managed for you, and a new connection is all it takes to get another IP.
• Pool size. A list is limited to the IPs you were given. A gateway draws from the whole pool, which for Storm rotating plans is 700,000+ IPs.
• Control. A list lets you pin a specific IP to a specific account forever and know exactly which address you’re on. A gateway doesn’t: you can’t choose or keep a particular exit IP beyond the gateway’s window.

That last point is the honest trade-off. If you need to say “account A always uses address X”, you want static IPs, not a backconnect gateway.

Per-request (Storm’s Main gateway) assigns a new exit IP to each new connection. It’s the right choice for collecting data from many pages where no page depends on the previous one: product listings, search result pages, public profiles, price checks. Each connection looks unrelated, so rate limits tied to a single IP matter less.

Note the word connection. A tool that keeps one keep-alive connection or one HTTPS tunnel open will send many requests through it from the same IP. That’s why “my IP doesn’t change” is the most common backconnect support question. The fix is on the client side: open new connections, don’t reuse one.

Timed rotation (Storm’s 3-minute and 15-minute gateways) keeps the same exit IP for a window, then moves to another. Use it for short multi-step flows where the site would be confused by an IP change halfway: logging in and reading a page, filling a form over several screens, keeping a shopping cart. The 3-minute gateway is USA only, uses a mix of IP types and is meant for account registration, social sites and browsing; it isn’t for search-engine scraping. The window is fixed, so plan your flow to fit inside it or to tolerate a switch at the end.

Residential ports work on a schedule too: each port’s IP changes every 5 minutes at fixed times (minute 1, 6, 11, 16 and so on each hour). A connection that is open at that moment can drop, so long-running jobs should reconnect and retry.

What you gain:

• One stable address to configure, in any tool that accepts an HTTP proxy.
• Access to a much larger pool than any list you could manage by hand.
• No rotation code, no dead-IP cleanup, no reloading lists when IPs change.
• Retries become simple: a failed request retried on a new connection usually leaves from a different IP.

What you give up:

• You can’t choose a specific exit IP or keep it beyond the gateway’s window.
• You can’t predict which IP comes next, so you can’t whitelist exit IPs on the target side.
• Mid-session switches can break logins if you pick a per-request gateway for a stateful task.
• Some checkers that test proxies by sending the same request twice get confused by the changing IP. ScrapeBox’s built-in proxy checker, for example, isn’t compatible with Storm gateways, although the gateways themselves work in ScrapeBox. Test in a browser instead.

A gateway port is not the same as a thread. On Storm rotating plans, the number of gateway ports depends on the plan, and the thread count is the total number of connections you may have open across all of them at once. Spreading 40 workers over two gateway ports still means 40 threads, not 80.

On residential, each port is a gateway with its own exit IP, and it accepts up to 50 threads that all share that IP. If you want 10 different home IPs active together, you need 10 ports. For the full breakdown of threads, ports and requests per second, see proxy threads explained.

• Scraping many independent pages: Main gateway, rotating plan.
• Search engines: Main gateway, and no more than a quarter of your threads (10 on a 40-thread plan).
• Short logged-in flows, sign-ups, social browsing: 3-minute gateway (USA) or 15-minute gateway.
• Sites that expect home connections: a residential port, one IP for 5 minutes at a time.
• Accounts that must keep one IP for weeks: not a backconnect job. Use dedicated or social proxies.

Setting a gateway up in code is covered in the Python requests guide and the cURL guide.