How to use a residential proxy: setup, sessions and cost math

A residential proxy routes your request through a real household IP, so the target site sees a consumer ISP instead of a datacentre. To use one: get a gateway host, port, username and password; encode geo and session flags in the username; point your HTTP client at it; verify the exit IP; then tune rotation and spend.

What you actually buy: a gateway, not an IP list

Almost every residential product works the same way. You do not receive thousands of IP addresses. You receive one hostname and port, plus credentials. Your client opens a connection to that gateway, the gateway picks an exit device from its pool, and your request leaves from that device's IP. Rotation, country selection and session persistence are configured by appending parameters to the proxy username rather than by changing hosts.

The pool itself comes from consumer devices. Independent research on the ecosystem lists the usual sourcing routes: SDKs bundled into apps, peer-to-peer bandwidth-sharing clients that pay users, leased ISP allocations, and — in the worst corner of the market — compromised devices and botnets (Spur). That last category is why sourcing matters more than pool size: an IP taken from a malware-infected router is both an ethics problem and a quality problem, because it is already flagged.

Expect friction at signup. Large providers gate residential access behind compliance review; Bright Data's documentation states that residential network access requires KYC approval and is available to verified companies only, across shared, IPv6 and dedicated types (Bright Data docs). Ports are usually limited to 80 and 443 by default, with anything unusual needing review.

How to use a residential proxy in seven steps

1. Choose the network before the vendor. Rotating residential for broad crawling and geo checks, sticky residential for multi-step flows, static ISP for anything tied to a logged-in account.
2. Create a zone or plan and copy the credentials. You need four values: host, port, username, password.
3. Add targeting to the username. Country, and sometimes city, state, ZIP or ASN, are appended as flags — for example user-country-us. Wrong syntax silently gives you a random exit, so test it.
4. Decide rotation or session. Either a new IP per request, or a session identifier that pins one IP for a defined window.
5. Wire it into your client. One environment variable and one proxy dict is usually the whole change.
6. Verify the exit IP and geolocation against an IP echo endpoint before running a single scrape job.
7. Add retry, backoff and a spend cap. Bandwidth burns on failures too, so cap the zone and log bytes per successful page.

The minimal integration, in curl and Python:

# curl: every request exits from a different household IP
curl -x http://USER-country-us:PASS@PROXY_HOST:PORT \
     https://ipinfo.io/json

# sticky: same exit IP for the whole session window
curl -x http://USER-country-de-session-a7f31:PASS@PROXY_HOST:PORT \
     https://ipinfo.io/json

import requests

PROXY = "http://USER-country-us:PASS@PROXY_HOST:PORT"
proxies = {"http": PROXY, "https": PROXY}

r = requests.get("https://ipinfo.io/json", proxies=proxies, timeout=30)
print(r.status_code, r.json()["ip"], r.json().get("country"))

# run it 5 times: rotating credentials should print 5 different IPs,
# a session-pinned username should print the same IP 5 times

Verify before you scale

That five-call loop is the single most useful test you can run. It catches three of the four most common setup mistakes: targeting flags that were ignored, a session ID that is not actually sticky, and credentials that fall back to a datacentre pool. The fourth mistake — TLS interception breaking on HTTPS — shows up as certificate errors, and is usually fixed by keeping the scheme http:// for the proxy URL itself while requesting https:// targets. For a fuller pattern with pools, backoff and per-request rotation in code, see how to rotate proxies in Python.

Rotating, sticky or static: pick the session model

Rotation is not a quality setting, it is a behaviour contract with the target. Rotate on every request and you look like many households; keep one IP and you look like one household coming back. Choose based on whether the target carries state.

Which network fits the job

A useful default: start on the cheapest network that works, measure block rate, and escalate only on the endpoints that fail. Most crawls do not need residential everywhere. Full parameter details for the rotating and sticky pools live on the residential proxies page, and the fixed-IP alternative on ISP proxies.

The honest cost math on residential bandwidth

Residential is metered per gigabyte, and a gigabyte covers everything the connection pulls: HTML, redirects, cookies, any images or fonts your headless browser fetches, and every failed attempt. Blocked responses are billed like successful ones. That is where budgets die.

Work it out at $0.80/GB:

• Plain HTTP fetch, 350 KB average page: roughly 2,900 pages per GB, about $0.0003 per page.
• Same target at a 70% success rate: you pay for about 1.4 attempts per success, so roughly $0.0004 per usable page.
• Headless browser with JS, CSS, fonts and XHR at 2.5 MB: around 400 pages per GB, about $0.002 per page — before retries, and before the cost of running the browser fleet.

Two levers change that math quickly. Blocking images, media and fonts in Playwright or Puppeteer often cuts rendered page weight by more than half. And moving retry-heavy targets onto a per-success API changes who eats the failures: the Web Scraping API charges $0.0002 per page ($0.001 with JS rendering) and nothing at all when a call fails. If your success rate on a target is 40%, the per-GB route is quietly 2.5x its sticker price while the per-success route is unchanged.

Free residential proxies, cheap plans and what Reddit gets right

Three related searches deserve blunt answers.

Free residential proxies. Someone pays for household bandwidth. If you are not paying, either your own bandwidth is being resold, the list is a scrape of misconfigured devices, or the exit is logging your traffic. Free lists also fail constantly, which makes your success-rate measurements meaningless. A provider free trial is a different thing and is the sensible way to test.

Cheap residential proxies. Cheap is fine when the discount comes from pool efficiency and honest metering, not from sourcing shortcuts. Ask two questions: how are peers recruited and compensated, and does unused traffic expire at the end of the month. Our budget line is documented on the cheap residential proxies page.

"Unlimited" residential. Unlimited bandwidth on a rotating residential pool is almost always thread-capped, speed-capped or fair-use-capped somewhere. Unlimited per IP is realistic on static ISP products, because you own that IP for the month.

Building your own network. The recurring Reddit thread about rolling your own residential pool underestimates the hard part. Renting a few home connections is easy; recruiting consenting peers, honouring withdrawal of consent, handling abuse complaints from ISPs, and keeping the pool healthy is a compliance operation, not a weekend project.

Compliance, detection and failure modes

A residential IP hides where the request came from; it does not change what you are allowed to collect. Terms of service, robots directives, rate limits, personal data rules and authentication boundaries all still apply, and "the proxy made me look like a household" is not a defence. This is general information, not legal advice — get counsel for your specific use case.

Expect detection to improve. Modern defences no longer rely on ASN lookups alone; they attribute IPs to known proxy services and correlate rotation patterns, geo mismatches and device telemetry, with vendors reporting hundreds of millions of anonymised IPs observed per quarter (Spur). Practically, that means a clean IP is necessary but not sufficient: TLS fingerprints, header order, timing and browser signals must match the story the IP tells. Our write-up on how residential proxies are detected covers the signals from the defender's side.

The failure modes worth instrumenting from day one: 407 responses (bad credentials or unwhitelisted source IP), ignored geo flags (username syntax), sudden latency spikes (poor exit peers — retry rather than escalate), 502s from IPv6-only exits hitting IPv4-only hosts, and success rates that drift down over hours (your fingerprint, not your IP pool). Vendors advertise sub-second response times and success rates above 99% on their own pools, for example 175M+ IPs and 99.95% success — treat those as best-case benchmarks against easy targets, and measure your own numbers per domain.

When to skip the proxy plumbing entirely

Proxies are the right primitive when you control the client: a browser automation suite, a checkout bot, an existing scraper with parsers you trust. They are the wrong primitive when what you actually want is the parsed content and someone else's retry logic. In that case, one HTTP call replaces the gateway, the rotation policy and the headless fleet:

curl https://api.quanticdata.io/v1/scrape \
  -H "Authorization: Bearer $QD_API_KEY" \
  -d '{ "url": "https://example.com" }'

{ "success": true,
  "data": { "markdown": "# Example Domain\n…" },
  "usage": { "cost_usd": 0.0002 } }

Residential proxies run underneath that call; the difference is that a failed attempt costs nothing and the retry log ships in the response. For agent workflows the same tools are exposed natively over MCP, so Claude, Cursor or your own loop can call search, scrape, map and crawl without ever seeing a proxy username — see the MCP server, or the endpoint and envelope reference in the documentation.

Most serious data teams end up running both: raw residential proxies for the flows that need a real browser and a real session, and a per-success API for the long tail of pages where paying for failures is the only real cost driver.