Rotation, Sessions and Geo-Targeting

A script sends three requests to the same proxy address, gate.example-proxy.com:7000. The target site logs three different visitors: one in Ohio, one in Texas, one in Oregon. The script changed nothing between requests. The gateway did.

One address, many exits: the backconnect gateway

Residential and mobile IPs cannot be handed out as a list. The devices behind them switch off, change networks and come back with new addresses. Providers solve this with a backconnect gateway: one stable hostname in front of a pool that never stops moving.

The client connects to the gateway and never learns the exit IP in advance. The gateway reads the username, picks a peer that matches and relays the traffic. Each peer keeps a connection open back to the provider, which lets the gateway reach devices that sit behind home routers.

Two consequences follow. Every request takes an extra hop through a consumer connection, so latency is higher and less even than on a datacenter proxy. Every choice about the exit, location and lifetime included, is made through the proxy credentials.

Rotate per request, or hold a sticky session

A gateway offers two main behaviors. In rotating mode, each new connection gets a fresh IP from the pool. In sticky mode, the client names a session and the gateway keeps sending that session through the same peer.

One detail trips up many first scripts. Rotation happens per connection, not per HTTP request. A client that keeps a connection alive and reuses it will hold the same exit IP for as long as that connection lasts. A scraper that expects a new IP on every page must open a new connection for every page.

A third mode sits between the two: timed rotation. The gateway holds one IP for a set interval and then swaps it, with no session ID involved. Dedicated mobile ports often work this way, and many add a link that forces a new IP on demand.

How long a sticky session lasts

A sticky session ends in one of three ways. The provider's time limit runs out, anywhere from a minute to several hours depending on the product. The client stops using the session ID. Or the peer disappears, because a phone left its Wi-Fi or a laptop lid closed.

The third case arrives without warning. Some gateways return an error, and others quietly continue on a new IP. Code that depends on one IP should check for a change and restart the flow, not carry on halfway through a login. Restarting means a new session ID and a clean cookie jar, from step one.

The last row matters for account work. A sticky session is built for minutes or hours. No residential peer can promise next week. Running multiple accounts can also breach a platform's terms of service, and the operator carries that risk.

Sessions and targeting in the username

Most gateways read their instructions from the proxy username. The account name comes first, followed by options. The lines below show the idea.

# Illustrative only. Exact syntax comes from the provider's docs.

USERNAME                              rotate, any country
USERNAME-country-us                   rotate, United States only
USERNAME-country-us-session-a1b2c3    hold one US exit IP
USERNAME-country-us-session-x9y8z7    hold a second US exit IP
USERNAME-country-de-city-berlin       rotate, Berlin only

The session ID is a string the client invents. The gateway has never seen a1b2c3 before, so it assigns a peer and remembers the pairing. The same ID returns the same IP until the session ends. A new ID gets a new IP.

That makes parallel identities cheap. Fifty session IDs through one gateway give fifty held IPs, each with its own cookie jar in the client. Dropping an ID and inventing another is how a script asks for a fresh IP on demand.

Traffic is metered at the gateway on per-GB plans. Blocked pages, retries and abandoned sessions all count toward the bill, which is one more reason to match the mode to the job.

Geo-targeting: country, state, city, ZIP, ASN

A German retailer shows German prices to German IPs. A search engine shows different local results in Dallas and in Houston. Geo-targeting lets a job pick the exit location to match, at five levels of precision.

• Country. The default level, and enough for prices, catalogs and most content checks.
• State or region. Useful where laws, taxes or offers differ inside a country.
• City. Needed for local search results, maps listings and delivery checks.
• ZIP or postal code. Offered by few providers, for store-level stock and local advertising.
• ASN or carrier. Picks the network, not the place. Ad verification on one mobile carrier is the typical job.

Each filter can only remove peers from the pool. Bright Data, Decodo and Oxylabs each state coverage of 195 countries, by their own count. A country count says little about how many peers are online in one mid-sized city on a weekday morning.

A thin pool shows up in three ways. The same IPs come around again sooner, so per-IP rate limits bite earlier. More requests fail because no matching peer is free. And some providers charge extra for city or ZIP targeting, or keep it for higher plans.

The rule is to target at the widest level the data requires. Country-level prices do not need a city. When a narrow pool runs dry, providers differ: some fail the request and some fall back to a wider area without saying so. Open What Is My IP through the proxy to see where an exit really lands.

Static IP lists versus gateways

Datacenter and ISP proxies usually arrive in the other format: a file of fixed addresses such as 198.51.100.24:8000, one per line. The two formats shift work between the provider and the client.

A static list is the right choice when the IP itself has value: a long-lived account, or a partner system that allowlists known addresses. A gateway is the right choice when the IP is disposable and volume matters. ProxyLook's rotating proxy page lists providers that sell gateway access.

Static lists need some care that gateways hide. Ask for IPs spread across several subnets, because sites often block a whole range when a few addresses in it misbehave. Keep a per-IP record of blocks and response times, and return dead addresses to the provider for replacement.

Sticky and rotating in Python

The first example holds one exit IP across three requests. The session ID in the username pins the IP. The requests.Session object keeps cookies, so the site sees one consistent visitor.

import uuid
import requests

URL = "https://httpbin.org/ip"
GATEWAY = "gate.example-proxy.com:7000"
session_id = uuid.uuid4().hex[:8]
user = f"USERNAME-country-us-session-{session_id}"
proxy = f"http://{user}:PASSWORD@{GATEWAY}"
proxies = {"http": proxy, "https": proxy}

with requests.Session() as s:
    for _ in range(3):
        r = s.get(URL, proxies=proxies, timeout=30)
        r.raise_for_status()
        print(r.json()["origin"])  # the same IP three times

The second example rotates. It has no session ID, and it avoids a shared Session on purpose. Each call to requests.get opens a new connection, so the gateway assigns a new peer each time.

import requests

URL = "https://httpbin.org/ip"
GATEWAY = "gate.example-proxy.com:7000"
proxy = f"http://USERNAME-country-us:PASSWORD@{GATEWAY}"
proxies = {"http": proxy, "https": proxy}

for _ in range(3):
    # A new connection per call, so a new exit IP per call.
    r = requests.get(URL, proxies=proxies, timeout=30)
    r.raise_for_status()
    print(r.json()["origin"])  # normally three different IPs

Run both before writing anything larger. If the sticky script prints different IPs, the username format is wrong for that provider. If the rotating script prints one IP three times, the plan or port is set to sticky by default. Either result is cheaper to find in a ten-line test than in a job that has already spent its traffic.