What is a residential proxy?
A residential proxy is a proxy server that routes your internet traffic through an IP address assigned by a consumer internet service provider (ISP) to a real household. When you send a request through a residential proxy, the website you're visiting sees an IP address belonging to Comcast, Verizon, BT, Deutsche Telekom or another home broadband provider, not a cloud server.
That one detail is why residential proxies exist. Websites treat traffic differently based on where it comes from. Requests from datacenter IP ranges (AWS, Google Cloud, DigitalOcean, OVH and the like) are statistically much more likely to be bots, so anti-bot systems scrutinise them, challenge them with CAPTCHAs or block them outright. Requests from residential IPs look like ordinary people browsing from home, so they get the benefit of the doubt.
If you need to collect data from well-protected websites, see search results as a local user would, test ads and content in different locations, or manage accounts without getting flagged, residential proxies are usually the right starting point. They're also the proxy type most buyers end up comparing when they look for the best proxies.
How residential proxies work
Residential proxy networks are built on top of real devices. Here's the typical flow:
- You connect to the provider's gateway, a single hostname and port such as
gate.provider.com:7777, using a username and password. - The gateway reads your parameters (country, city, session ID) from your username or settings.
- The gateway picks a residential device (called an exit node or peer) that matches, and forwards your request through it.
- The target website sees the residential IP, responds, and the response travels back through the same path to you.
Where do the devices come from? Reputable providers recruit them through opt-in programmes: apps and SDKs that let users share idle bandwidth in exchange for payment, premium features or an ad-free experience. Consent and fair compensation vary a lot across the industry, which is why sourcing is worth asking about. We cover it in detail in how proxy providers source IPs and ethically sourced proxies.
Because the exit nodes are real devices, they come and go. A phone goes to sleep, a laptop gets closed, a router restarts. Providers manage this with large pools and automatic failover, but it explains why residential proxies are slower and less predictable than datacenter proxies.
Inside a residential proxy network
The four-step flow above is the simple version. Knowing what happens underneath explains most of the behaviour you'll see in practice: why speeds vary, why IPs sometimes repeat, and why sessions occasionally drop.
The gateway layer
When you connect to a residential provider, you don't connect to a home device directly. You connect to a gateway (sometimes called a super proxy or entry node) run by the provider in a datacenter. The gateway authenticates you, reads your targeting and session parameters, enforces your plan's limits, and counts your bandwidth. Providers run gateways in several regions so that the first hop is short wherever you are.
The routing layer
Behind the gateway, the provider tracks which peers are online, where they are, what network they're on, how fast they are and how recently they were used. When you request a US exit in Chicago, the routing layer picks a suitable peer from that set. Good routing avoids peers that are slow, overloaded or recently used on the same target.
The peer layer
Peers are the real devices: desktop computers, phones, smart TVs, routers and other devices whose owners have agreed (on reputable networks) to share bandwidth. Each peer runs software, usually an SDK inside an app or a dedicated bandwidth-sharing app, that keeps a connection open to the provider and relays traffic when asked. The peer's home connection determines speed, and the peer's IP is the one websites see.
Failover and retries
Peers disappear all the time: a phone leaves Wi-Fi, a laptop sleeps, a user closes an app. When a peer drops during your request, some providers transparently retry through another peer; others return an error and leave the retry to you. Either way, a small percentage of failed connections is normal on residential networks.
IP churn
Many home connections get new IPs from their ISP periodically, and peers join and leave the network constantly. That's why providers quote large cumulative IP counts: over a month, the network sees many more IPs than are online at any moment. It's also why "the same IP" isn't always available again later.
Why IPs sometimes repeat
If you send thousands of requests through a narrowly targeted location, you'll see repeats, because only so many peers are online there at once. Broader targeting, spreading jobs over time and avoiding unnecessary city targeting all increase diversity. See proxy pool size.
Not all residential IPs are the same
"Residential" covers several kinds of connection, and they behave differently.
- Fixed broadband (cable, DSL, fibre): the classic residential IP. Usually stable for hours or days, good speeds, strong trust on most sites.
- Wi-Fi devices on home networks: phones and tablets on home Wi-Fi share the household's broadband IP, so they look like fixed broadband to websites.
- Mobile data connections: phones on 4G or 5G use carrier IPs, often shared by many users through CGNAT. Some residential pools include these; they carry very high trust but change frequently. See mobile proxies.
- IPv6 residential: many ISPs now give households IPv6 addresses as well. IPv6 residential exits are less common in commercial pools and only useful on targets that support IPv6. See IPv6 proxies.
Most providers don't let you choose between these subtypes, though some offer mobile as a separate product or filter. If your target treats mobile traffic differently from broadband, ask your provider whether you can control the mix.
Sticky sessions in depth
Sticky sessions are the feature that makes residential proxies usable for anything stateful: logins, carts, multi-page flows, browser sessions. They're also the most common source of confusion.
How sticky sessions work
When you include a session identifier in your request (usually in the username, sometimes via a port range), the gateway remembers which peer it assigned to that identifier and keeps routing your traffic through it. Use a new identifier and you get a new peer. Leave it out and you typically rotate on every request or connection.
Session lifetime
Providers set a maximum lifetime, often configurable from a minute up to many hours. Geonode, for example, lists sticky sessions of up to 24 hours. Two things end a session early:
- The lifetime expires, and the gateway assigns a new peer to the identifier.
- The peer goes offline, in which case the provider either assigns a new peer (silently changing your IP) or returns an error.
That's why long sessions can't be guaranteed on any residential network, however long the configured maximum. If your workflow can't tolerate an IP change, use static residential (ISP) proxies instead.
Choosing a session length
| Workflow | Suggested session | Why |
|---|---|---|
| Independent pages (product pages, listings) | None (rotate per request) | Maximum diversity |
| Pagination through search results | 1 to 5 minutes | Keeps cookies and pagination consistent |
| Login then a few actions | 10 to 30 minutes | Covers the whole flow |
| Browser automation per job | 10 to 30 minutes | One identity per browser context |
| Long queue or monitoring session | Up to several hours | Avoids losing state |
| Account that must always use the same IP | Use ISP proxies | Residential sessions can't promise permanence |
Detecting IP changes in code
If an IP change mid-session would break your workflow, check it. Call an IP echo endpoint at the start of a session and periodically during it, and restart the flow cleanly if the IP changes.
import requests
def current_ip(session):
return session.get("https://api.ipify.org", timeout=20).text.strip()
s = requests.Session()
s.proxies = {"http": PROXY_WITH_SESSION, "https": PROXY_WITH_SESSION}
start_ip = current_ip(s)
# ... perform a few steps of the flow ...
if current_ip(s) != start_ip:
raise RuntimeError("Exit IP changed mid-session; restart the flow with a new session ID")Don't over-check: every echo request costs a little bandwidth and time. Checking at the start and before critical steps is usually enough.
Geo-targeting in depth
Geo-targeting is one of the main reasons people buy residential proxies. It's also where expectations and reality can differ.
How location is determined
Websites don't know where a residential IP physically is. They look it up in IP geolocation databases, which estimate location from ISP registration data, network measurements and other signals. Providers use similar databases to label their peers. When the provider's database and the website's database agree, you see what you expect. When they disagree, a "Chicago" IP might look like a suburb, a different city or, occasionally, a different state to the target.
Accuracy by level
- Country: very reliable.
- State or region: usually reliable.
- City: good for large cities, less reliable for small towns and suburbs.
- ZIP or postcode: approximate at best; treat with caution.
- ASN (specific ISP): reliable, since it's based on network registration rather than estimated location.
The availability trade-off
The narrower your targeting, the fewer peers match, and the more you'll see repeats, slower speeds and occasional failures. Use the broadest targeting that gives correct results. If a site only localises by country, don't pay (in money or in performance) for cities.
Verifying targeting
Check a sample of exit IPs against two or three geolocation services, and, more importantly, check the target itself. If you need Chicago search results, look at the results page for local signals (the location shown in the footer, local business listings) rather than trusting the label on the IP.
When location comes from more than the IP
Many sites also use account settings, cookies, browser language, timezone, and explicit location pickers. For accurate local results, set those to match the exit as well. See geo-targeted proxies and the walkthroughs above.
Rotating vs static residential proxies
There are two main flavours.
Rotating residential proxies
Rotating residential proxies assign a new IP from the pool for every request, or keep one for a "sticky session" of a few minutes before rotating. They're sold per GB of traffic. This is the classic residential proxy product and the right choice for most scraping and data collection.
Static residential proxies (ISP proxies)
Static residential proxies, more commonly called ISP proxies, give you a fixed IP that's registered to a consumer ISP but hosted in a datacenter. They're fast and they don't change, but the pool is much smaller and less diverse. They're sold per IP. They're ideal for account management, long sessions and sneaker proxies.
| Rotating residential | Static residential (ISP) | |
|---|---|---|
| IP changes | Per request or per sticky session | Never (unless you replace it) |
| Pool size | Millions of IPs | Hundreds to thousands |
| Speed | Variable | Fast and consistent |
| Pricing | Per GB | Per IP per period |
| Best for | Scraping, geo-testing, unique IPs per request | Accounts, checkouts, long sessions |
For the full comparison, read ISP vs residential proxies.
When do you actually need residential proxies?
Residential proxies cost more than datacenter proxies, so it's worth being honest about when they're needed.
You probably need residential proxies if:
- Your target uses commercial bot protection (Cloudflare Bot Management, Akamai, Datadome, HUMAN/PerimeterX, Kasada) and datacenter IPs get challenged or blocked.
- You need to see location-specific content, such as local search results, local prices, or region-locked pages.
- You need a different IP for each of thousands or millions of requests.
- You're managing accounts on platforms that flag hosting IPs.
- You're verifying that ads display correctly to real users in specific places.
You probably don't need them if:
- Your target is a public API, government data portal or small site that doesn't block datacenter IPs.
- You're doing internal testing or development.
- You're scraping at very low volumes where a few datacenter IPs and polite rate limits suffice.
The simplest test: try your target with a handful of datacenter proxies first. If you get consistent success, save your money. If you see CAPTCHAs, 403s or empty pages, move to residential. Read residential vs datacenter proxies for a deeper look.
Residential proxy use cases
| Use case | Why residential works | Guide |
|---|---|---|
| Web scraping protected sites | Higher trust, fewer blocks | Web scraping proxies |
| E-commerce price monitoring | Retailers block datacenter ranges | Price monitoring proxies |
| Search engine results | Local, unpersonalised SERPs | Google SERP scraping proxies |
| Ad verification | See ads as real local users | Ad verification proxies |
| Sneaker raffles | Unique IP per entry | Residential proxies for sneakers |
| Browser automation | Real-user IPs for headless browsers | Puppeteer proxies |
| Social media accounts | Platforms penalise hosting IPs | Social media management proxies |
| Travel and fares | Prices vary by location | Travel fare aggregation proxies |
| Brand protection | Find counterfeits and abuse | Brand protection proxies |
Residential proxies by job, in depth
The use-case table above lists the common jobs. Here's how each one actually uses residential proxies, with the settings that tend to work.
Price and product intelligence
Retailers and marketplaces are among the most protected sites on the web, and many show different prices, stock or delivery options by location. Residential proxies get past datacenter blocks and let you see local variations.
- Session pattern: rotate per request for independent product pages; use a sticky session when you must set a store or ZIP first.
- Targeting: country for national prices; state or city when delivery location changes the price or availability.
- Fetch method: HTML or JSON endpoints wherever possible. Product pages in a full browser are very expensive per GB.
- Watch for: personalised prices and A/B tests, which vary between sessions. Repeat checks and compare.
See price monitoring proxies, best proxies for e-commerce scraping and Geonode for price monitoring.
Search engine results
Search engines localise heavily and challenge automated traffic from datacenter ranges quickly.
- Session pattern: rotate per query; avoid long sessions that build up a history.
- Targeting: city for local results, combined with the search engine's own location and language parameters.
- Rate: keep it low per IP and back off on challenges.
- Alternative: at high volume, a SERP or search API priced per query can be cheaper and more stable.
See Google SERP scraping proxies, best proxies for SEO rank tracking and Geonode for local SEO.
Ad verification
Advertisers and agencies check that ads appear where they should, look right, and aren't being hijacked by fraud or malicious redirects. That requires seeing the page as a real user in a specific place.
- Session pattern: sticky for the length of a page visit and any redirect chain.
- Targeting: city or region matching the campaign; sometimes ASN to check specific ISPs.
- Fetch method: a real browser with images and scripts enabled, because ads are images and scripts.
- Watch for: frequency capping and personalisation. Fresh browser profiles avoid skewed results.
See ad verification proxies and Geonode for ad verification.
Travel fares and hotel rates
Airlines, online travel agencies and hotel sites vary prices by point of sale, currency, device and session. They also use strong bot protection.
- Session pattern: sticky for a search flow (search, results, details).
- Targeting: country (point of sale) is usually what matters; city occasionally.
- Rate: travel sites watch search volume closely; spread queries over time.
- Watch for: cached fares and session-specific pricing; validate by repeating searches.
See travel fare aggregation proxies, Geonode for travel fares and Geonode for hotel rates.
Brand protection
Brands search marketplaces, social platforms and websites for counterfeits, unauthorised sellers and trademark abuse. Many infringing sites geo-block or cloak content from known corporate and datacenter IPs.
- Session pattern: rotate for discovery; sticky for collecting evidence from a specific listing.
- Targeting: the markets where infringement happens, which may differ from your home market.
- Record keeping: screenshots, timestamps, URLs and exit locations for evidence.
See brand protection proxies and Geonode for brand protection.
Social media and community research
Public social content is used for market research, sentiment analysis and trend tracking. Platforms are strict about automated access and often restrict logged-out views.
- Session pattern: rotate for public pages where allowed; never rotate during logged-in sessions.
- Accounts: if you manage accounts, use static IPs (ISP proxies), not rotating residential.
- Rules: platforms' terms and data protection law are significant here. Collect only what you need.
See social media management proxies, market research proxies and Geonode for market research.
AI training data and AI agents
Large-scale collection of web content for AI raises the stakes on both blocking and compliance. Many sites now publish explicit preferences for AI crawlers.
- Respect opt-outs in robots.txt and site terms.
- Use datacenter first for sites that allow crawlers, and residential only where justified.
- For agents that browse on a user's behalf, a scraping API or MCP server that returns clean Markdown is often simpler than raw proxies.
See AI training data proxies, Geonode for AI training data and Geonode for AI agents.
Localisation and QA testing
Product teams check that their own websites and apps show the right language, currency, prices, legal notices and content in each market.
- Session pattern: sticky per test run.
- Targeting: country, and sometimes city for local features.
- Proxy type: your own site won't block datacenter IPs, so residential is only needed when third-party services (payments, maps, ads) behave differently with residential traffic.
See Geonode for localization testing.
Security and privacy with residential proxies
Residential proxies route your traffic through other people's connections. That raises sensible questions in both directions.
Protecting your own data
- Use HTTPS for everything. With HTTPS through an HTTP proxy, the exit device and the provider see the domain you connect to but not the content of your requests or the pages returned. Never send credentials over plain HTTP through any proxy.
- Don't disable certificate checks to "fix" errors. That would let any intermediary read and alter your traffic.
- Keep sensitive accounts off shared pools where possible. For accounts, use static IPs you control.
- Protect proxy credentials in a secrets store, with sub-users per project.
Respecting the people whose IPs you use
- Choose providers that pay or reward peers and collect explicit consent.
- Don't use residential traffic for anything abusive. It's a real person's IP that gets the blame.
- Avoid unnecessary bandwidth. Peers share their connections; efficient scraping is also considerate scraping.
Avoiding compromised networks
As covered in the sourcing section, some networks have been built on malware-infected devices. Buying from them puts your traffic through compromised machines and funds the people who compromised them. Ask the sourcing questions and prefer providers with clear answers. See ethically sourced proxies.
Residential proxies, unblockers or scraping APIs?
Residential proxies give you trusted IPs. They don't solve CAPTCHAs, render JavaScript or manage fingerprints for you. Two higher-level products do.
| Residential proxies | Web unblocker | Scraping API | |
|---|---|---|---|
| You get | IPs | IPs plus automatic retries, fingerprints and challenge handling | Finished pages or data |
| You handle | Everything above the IP | Parsing | Little or nothing |
| Billing | Per GB | Per request or per GB | Per request |
| Best for | Teams with engineering capacity and many targets | Hard targets where you still want raw responses | Small volumes, quick projects, agents |
Many teams start with residential proxies and add an unblocker or API for a handful of stubborn targets. Some providers sell all three, which makes comparison easy. Geonode, for example, offers residential proxies alongside a Scraper API that returns HTML or Markdown with optional JavaScript rendering. See web unblocker proxies, scraping API vs proxies and the Geonode Scraper API.
How much do residential proxies cost?
Residential proxies are usually priced per gigabyte of traffic. Market rates have dropped sharply over the last few years. At the time of writing, typical ranges are:
- Pay-as-you-go and small plans: roughly $3 to $8 per GB.
- Mid-tier monthly plans (tens of GB): roughly $2 to $4 per GB.
- High-volume and enterprise contracts (TB-scale): often $1 per GB or less.
Factors that push the price up include city or ASN targeting, premium "unblocker" layers and mobile IPs mixed into the pool. Factors that push it down include annual commitments, volume, and promotional pricing.
How to estimate how many GB you need
- Open your target page in Chrome with DevTools, Network tab, "Disable cache" ticked.
- Reload and read the total transferred at the bottom of the panel.
- Multiply by the number of pages per month.
- Add 15 to 30% for retries and overhead.
A modern retail product page can easily transfer 2 to 5 MB with images and scripts, whereas the underlying JSON API might be 20 KB. That's a 100x difference in proxy cost. Blocking images and fonts, or hitting APIs directly, is the single biggest saving you can make. See proxy bandwidth pricing explained and cheap proxies.
Residential proxy pricing in depth
The price ranges above are a starting point. Here's how to read pricing pages and model what you'll actually pay.
How tiers work
Most providers sell residential traffic in tiers: the more GB you buy at once (or commit to monthly), the lower the price per GB. The drop between the smallest and largest tiers can be large. Two consequences:
- Small buyers pay the most per GB. That's normal. Don't compare your entry-tier price with someone else's enterprise rate.
- Jumping a tier can be cheaper than staying. If your usage sits just below a tier boundary, the next tier may cost little more in total and give you a buffer at a lower rate.
Subscription vs pay-as-you-go
Subscriptions usually have lower per-GB prices but reset unused traffic each month. Pay-as-you-go balances often cost more per GB but don't expire (check the terms). The cheaper option depends on how evenly you use traffic.
| Your usage pattern | Usually cheaper |
|---|---|
| Steady, predictable each month | Subscription at the right tier |
| Uneven, seasonal or occasional | Non-expiring pay-as-you-go |
| Testing or backup | Non-expiring pay-as-you-go |
| Very high and steady | Volume subscription or unlimited plan |
Geonode, for instance, bills residential traffic per GB with no expiry on purchased bandwidth, and also offers separate unlimited residential plans for very high, steady volume.
What counts as traffic
Providers typically count both upload and download, including headers and TLS handshakes. Small requests therefore cost a bit more than their body size suggests. Failed requests usually count too, up to the point they failed. Some providers don't charge for certain errors; check.
Add-ons that change the price
- Granular targeting (city, ZIP, ASN) sometimes costs more or draws from a smaller premium pool.
- Mobile-only or premium pools cost more.
- Unblocker features are usually billed separately.
- Dedicated support and SLAs come with enterprise contracts.
A worked monthly model
Suppose you collect 300,000 product pages a month from three retailers.
| Retailer | Method | KB per success | Success rate | GB per month (with 20% overhead) |
|---|---|---|---|---|
| A | JSON endpoint | 30 | 98% | about 11 |
| B | HTML via HTTP client | 180 | 95% | about 68 |
| C | Browser with assets blocked | 700 | 92% | about 274 |
Total: roughly 350 GB a month, nearly 80% of it from retailer C. The obvious next step isn't a cheaper provider; it's finding a lighter way to fetch retailer C. Run this model for your own targets before choosing a tier.
Residential coverage around the world
Residential networks reflect where their peers live, so coverage follows population, internet adoption and the reach of the apps that recruit peers.
- North America: deep coverage in the US and Canada, with good state and city availability. See US proxies.
- Western Europe: strong in the UK, Germany, France, Italy, Spain and the Netherlands. City targeting works well in major cities. See UK proxies.
- Eastern Europe: generally good, with large pools in several countries.
- Latin America: strong in Brazil and Mexico; thinner in smaller countries, and mobile-heavy.
- Asia: large pools in India, Indonesia, the Philippines, Vietnam, Thailand and Japan; variable elsewhere. Mainland China is a special case that many providers restrict.
- Middle East and Africa: improving, uneven, and worth testing country by country.
If a market matters to you, test it specifically: ask the provider for typical live IP counts there, run your benchmark at the hours you'll work, and check geo accuracy at the level you need.
A short history of residential proxies
Residential proxies grew out of a simple problem. As websites learned to identify datacenter IP ranges, anyone collecting data at scale needed IPs that looked like ordinary users. Early residential networks were built on browser extensions and free VPN apps whose users' bandwidth was resold, often with consent buried in long terms. Some networks were worse, built on malware.
Over the following years, the market professionalised. Larger providers moved to explicit opt-in SDKs, bandwidth-sharing apps that pay users, and published sourcing policies. Prices fell sharply as networks grew and competition increased. Enforcement actions against botnet-based proxy services, along with public warnings from authorities, made sourcing a mainstream buying criterion.
Today, residential proxies are a standard tool for price intelligence, ad verification, SEO, security research and data collection. The core technology is the same as it was a decade ago; what has changed is scale, price, tooling and the expectation that providers can explain where their IPs come from.
Residential proxy myths
"Residential IPs can't be blocked"
They can, and they are, when behaviour or fingerprints look automated, or when a specific IP has been abused. Residential IPs start with more trust; they don't keep it automatically.
"The biggest pool is the best pool"
Live availability in your locations and the cleanliness of the IPs matter more than a cumulative total.
"Sticky sessions last as long as you set them"
They last up to the configured length, unless the peer goes offline first. Plan for occasional early changes.
"City targeting is always accurate"
It depends on geolocation databases that sometimes disagree. Verify on the target.
"Residential proxies are anonymous, so anything goes"
Providers log usage, cooperate with lawful requests, and close accounts for abuse. Websites can still identify you through accounts, fingerprints and behaviour.
"Residential is too expensive for scraping"
Fetched sensibly (HTML or JSON, assets blocked, no repeated fetches), residential traffic can be very affordable. It's full-page browser scraping of heavy sites that gets expensive.
How to choose a residential proxy provider
Use this checklist when you compare providers. Our residential proxy providers compared page applies it to well-known names.
- Country coverage and real availability. Not "195 countries", but how many live IPs in the countries you need.
- Targeting granularity. Country, state, city, ZIP, ASN. Only pay for what you'll use.
- Session control. Maximum sticky session length and how reliably sessions hold.
- Success rate on your targets. Test it yourself. See how to test proxies before buying.
- Speed. Median and 95th-percentile response time.
- Protocol support. HTTP, HTTPS and SOCKS5.
- Traffic expiry. Does unused traffic roll over or vanish?
- Sourcing and compliance. Can they explain how peers consent? Do they have KYC for customers?
- Dashboard and API. Sub-users, usage stats, IP whitelisting, proxy list generators.
- Support. Live chat, response time, technical depth.
Shortlists of providers worth testing: best residential proxies and best cheap residential proxies.
Geonode residential proxies
We're a Geonode affiliate. Here's how its residential offer lines up against the checklist above, so you can decide whether it belongs on your test list.
| Checklist item | Geonode residential, at the time of writing |
|---|---|
| Pricing model | Per GB, with purchased bandwidth that doesn't expire |
| Unlimited option | Separate unlimited residential plans priced by speed tier |
| Targeting | Country, state, city and ASN |
| Sessions | Rotating, or sticky for up to 24 hours |
| Protocols | HTTP, HTTPS and SOCKS5 |
| Sourcing | Geonode states its residential IPs come from opt-in partners |
| Dashboard | Endpoint generator in host:port:username:password format, usage statistics, active sticky sessions, block list |
| Extras | Chrome extension, scraping APIs, integrations with antidetect browsers and automation tools |
Where it's a strong fit
- Irregular or seasonal usage, because traffic you don't use stays in your account.
- Testing and backup roles, for the same reason.
- Geo-targeted research, thanks to city and ASN targeting from the same balance.
- Teams that also need ISP or datacenter proxies, which Geonode sells under the same account.
What to test
Run the standard test from our how to test proxies before buying guide on your own targets: success rate on content (not just status codes), median and p95 latency, bytes per success, geo accuracy for the locations you need, and how well sticky sessions hold at the lengths you plan to use. Compare with at least one other provider from best residential proxies.
For deeper coverage of Geonode's products and use cases, see the Geonode proxies review, Geonode for web scraping and Geonode unlimited residential proxies.
Setting up residential proxies
Most providers use a gateway with parameters encoded in the username. A typical pattern looks like this (every provider's syntax differs, so check their docs):
Host: gate.example-provider.com
Port: 7777
Username: customer-USER-country-us-city-chicago-session-abc123-sesstime-10
Password: YOURPASSWORDChanging session-abc123 to a new random value gives you a new IP. Omitting the session parameter usually rotates on every request.
Using it from Python:
import requests
proxy = "http://customer-USER-country-us-session-abc123:PASS@gate.example-provider.com:7777"
r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=30)
print(r.json())And from Puppeteer:
const browser = await puppeteer.launch({
args: ['--proxy-server=http://gate.example-provider.com:7777'],
});
const page = await browser.newPage();
await page.authenticate({ username: 'customer-USER-country-us', password: 'PASS' });
await page.goto('https://httpbin.org/ip');More detail for each tool: Python requests proxies, Puppeteer proxy authentication, Playwright proxies, Selenium proxies and Scrapy proxies.
Residential proxies in your code: patterns that work
The setup section shows a single request. Real jobs need rotation, concurrency, retries and session handling. These patterns use a placeholder gateway; your provider's dashboard will give you the real host, port and username syntax.
A small helper for building proxy URLs
Keeping proxy construction in one place makes switching providers or changing targeting a one-line change.
import os
import secrets
HOST = os.environ["PROXY_HOST"]
PORT = os.environ["PROXY_PORT"]
USER = os.environ["PROXY_USER"]
PASS = os.environ["PROXY_PASS"]
def proxy_url(country=None, session=None):
user = USER
if country:
user += f"-country-{country}"
if session:
user += f"-session-{session}"
return f"http://{user}:{PASS}@{HOST}:{PORT}"
def new_session_id():
return secrets.token_hex(4)The -country- and -session- suffixes are a common convention, but every provider differs. Adjust the helper to match your provider's documentation.
Rotating per request with retries
import requests
def fetch(url, country="us", attempts=3):
for n in range(attempts):
proxy = proxy_url(country=country) # no session: rotate
try:
r = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=30)
if r.status_code == 200 and "captcha" not in r.text.lower():
return r.text
except requests.RequestException:
pass
return NoneNote the content check. Blocks often come back as a 200 with a CAPTCHA page, so a status check alone overstates success.
Concurrency with asyncio
For throughput, run requests concurrently, but cap concurrency per target so you stay polite.
import asyncio
import aiohttp
async def fetch(session, url, sem):
async with sem:
proxy = proxy_url(country="us")
try:
async with session.get(url, proxy=proxy, timeout=aiohttp.ClientTimeout(total=30)) as r:
return url, r.status, await r.text()
except Exception as e:
return url, None, str(e)
async def main(urls):
sem = asyncio.Semaphore(20) # at most 20 requests in flight
async with aiohttp.ClientSession() as session:
return await asyncio.gather(*(fetch(session, u, sem) for u in urls))A sticky session for a multi-step flow
s = requests.Session()
p = proxy_url(country="us", session=new_session_id())
s.proxies = {"http": p, "https": p}
s.get("https://example.com/search?q=widgets", timeout=30)
s.get("https://example.com/search?q=widgets&page=2", timeout=30)Everything in the flow goes through the same exit until the session ends. Start a new session ID for the next flow.
Scrapy
In Scrapy, set the proxy per request in meta, usually from a downloader middleware so every request gets one:
class ResidentialProxyMiddleware:
def process_request(self, request, spider):
request.meta["proxy"] = proxy_url(country="us")See Scrapy proxies for retry and ban-detection middleware.
Node.js
import axios from 'axios';
import { HttpsProxyAgent } from 'https-proxy-agent';
const agent = new HttpsProxyAgent(process.env.PROXY_URL);
const res = await axios.get('https://httpbin.org/ip', { httpsAgent: agent, proxy: false });
console.log(res.data);Different Node HTTP clients take proxies differently; axios and undici each have their own options, and recent Node versions can honour standard proxy environment variables. See Node.js proxies.
Browsers
For Puppeteer and Playwright, give each browser context its own sticky session and match the timezone and language to the exit. See Puppeteer proxies and Playwright proxies.
Measuring residential proxy quality yourself
Provider dashboards show your usage, not your success. This short script gives you the numbers that matter for one target.
import statistics
import time
import requests
def benchmark(url, n=200, marker="<title>"):
ok, times, sizes, ips = 0, [], [], set()
for _ in range(n):
proxy = proxy_url(country="us")
t0 = time.time()
try:
r = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=40)
dt = time.time() - t0
if r.status_code == 200 and marker in r.text:
ok += 1
times.append(dt)
sizes.append(len(r.content))
except requests.RequestException:
pass
return {
"success_rate": ok / n,
"median_s": statistics.median(times) if times else None,
"p95_s": statistics.quantiles(times, n=20)[18] if len(times) >= 20 else None,
"avg_kb": sum(sizes) / len(sizes) / 1024 if sizes else None,
}Replace marker with something that only appears on a real content page (a product price element, for example). Run it at the hours you'll actually work, against each target and each provider you're comparing. To check IP diversity, run a separate loop against an IP echo endpoint and count unique IPs and /24 subnets. See proxy speed test.
Common residential proxy mistakes
- Rotating mid-session. If you log in or add to cart, keep the same IP. See sticky vs rotating sessions.
- Assuming the IP fixes everything. Modern bot protection weighs browser fingerprint, TLS fingerprint and behaviour as much as IP. See browser fingerprinting and proxies.
- Downloading everything. Images and video eat paid bandwidth fast.
- Hammering one target. Even with millions of IPs, request patterns can be detected. See avoiding IP bans when scraping.
- Leaking your real IP. Check for DNS leaks and WebRTC leaks in browser setups.
- Ignoring legal and ethical limits. Read are proxies legal? and ethical web scraping.
Residential proxies in practice: three walkthroughs
Walkthrough 1: Collecting localised prices
A retailer shows different prices in different US states. You need prices for 500 products in California, Texas and New York.
- Use state-level targeting:
country-us-state-california, and so on. See geo-targeted proxies. - For each state, open a sticky session, set the retailer's own location or ZIP selector, and keep that session for the batch of product pages.
- Fetch HTML with an HTTP client where possible; use a browser only if prices load via JavaScript you can't call directly.
- Validate prices and record the state and session used.
Walkthrough 2: Running a headless browser on a protected site
- One browser context per sticky session, 10 to 15 minutes long.
- Block images, fonts and media to save bandwidth.
- Match timezone and language to the exit location.
- Detect challenge pages and rotate to a new session when blocked.
See Puppeteer proxies and Playwright proxies.
Walkthrough 3: Checking search results by city
- Target the city (or the nearest available) with per-request rotation.
- Add the search engine's own location and language parameters.
- Keep request rates low and back off on challenges.
See best proxies for SEO rank tracking.
Worked example: a five-country price study
Walkthrough 1 above covers prices in three US states. Here's a bigger project end to end, to show how the pieces in this guide fit together.
The brief
A consumer electronics brand wants to compare the retail prices of 400 of its products across five countries (the US, UK, Germany, France and Japan), on two major retailers per country, weekly for three months.
Step 1: Scope the requests
400 products × 2 retailers × 5 countries = 4,000 product pages per week, about 52,000 over the quarter. Small, but spread across ten retailers with different defences.
Step 2: Test each retailer
Each retailer is tested with no proxy, then datacenter proxies, then residential, at a polite rate. Results:
- Three retailers work with datacenter proxies.
- Six need residential proxies.
- One needs a browser, because prices load through a script that's hard to call directly.
Step 3: Choose fetch methods
For the six residential retailers, the team looks for JSON endpoints. Four have them. The other two use HTML via an HTTP client. The browser-based retailer runs in Playwright with images, media and fonts blocked.
Step 4: Configure sessions and targeting
Country targeting for each country. Rotation per request for product pages, except for two retailers that need a location cookie set first; those use 10-minute sticky sessions per batch of 50 products.
Step 5: Estimate bandwidth
| Group | Pages per week | KB per page | GB per quarter (with overhead) |
|---|---|---|---|
| Datacenter retailers | 1,200 | 200 | about 3 (datacenter) |
| Residential JSON | 1,600 | 25 | about 0.6 |
| Residential HTML | 800 | 180 | about 2.2 |
| Residential browser | 400 | 800 | about 5 |
Total residential traffic for the quarter: under 10 GB. On a non-expiring plan, one modest purchase covers the whole study, with some left over.
Step 6: Validate
Each run checks that every page contained a price, flags outliers (a price ten times higher than last week usually means a parsing error or a different product variant), and records the exit country. A spot check of 20 pages per country compares collected prices with a manual check through a browser extension on the same exit country.
Step 7: Report
Prices are normalised to one currency with the exchange rate on the collection date. The final report notes method, dates, retailers and proxy configuration, so the results can be reproduced.
What made it cheap and reliable
Routing each retailer to the cheapest proxy type that worked, finding JSON endpoints, sticky sessions only where needed, and validation built in from the start. A provider with country targeting and non-expiring traffic, such as Geonode, suits this kind of periodic study well.
Three ways to run residential jobs
How you run your workers affects cost and reliability as much as which provider you choose.
A single script
One process, a loop or a small async pool, run on a schedule. Simple and perfect for small jobs. Weaknesses: no resumability if it crashes, limited throughput, and success data lives in log files. Add a simple state file or database table of completed URLs and it becomes surprisingly robust.
A worker fleet with a queue
URLs in a queue, several workers pulling from it, results and outcomes written to a database. Scales well, resumes cleanly, and makes per-domain limits and retry queues straightforward. This is the standard architecture for medium and large scraping operations.
Serverless or scheduled cloud functions
Each function invocation handles a small batch. Easy to scale and pay-per-use, but cold starts, execution time limits and outbound connection limits can complicate long browser sessions. Works well for HTTP-client jobs with modest per-invocation work.
Whichever you choose, keep the proxy configuration in one helper, log outcomes per request, and make retries go through a new IP.
Questions to ask residential provider support
A short support conversation before buying tells you a lot. Ask:
- How many residential IPs are typically live in [my countries] at [my working hours]?
- Is city or ASN targeting drawn from the same pool and priced the same as country targeting?
- What is the maximum sticky session length, and roughly how often do sessions end early?
- Does purchased traffic expire, and if so, when?
- How is traffic counted? Are failed requests charged?
- Which targets or categories do you block?
- How are residential peers recruited, and how do they consent?
- Do you support SOCKS5 on residential gateways?
- Can I create sub-users with traffic limits?
- What are your support hours and channels, and is there a status page?
Clear, specific answers are a good sign. Vague or evasive answers on sourcing, expiry or blocking are a reason to keep looking.
Proxy tip: If you're comparing types on your own targets, a provider that offers several of them saves time. Geonode lets you buy residential traffic by the GB, ISP IPs by the month and datacenter traffic by the GB, then compare results side by side. See our Geonode proxies guide.
How different roles use residential proxies
The same residential plan gets used very differently depending on who's using it.
Developers and data engineers
They build the scrapers, pipelines and monitoring. Their concerns are reliability, throughput and cost per success. They use rotating sessions for stateless pages, sticky sessions for flows, a proxy helper in code, and per-domain metrics. They're the people who benefit most from good documentation, endpoint generators and usage APIs.
Analysts and researchers
They need data, not infrastructure. They often use residential proxies through no-code scrapers, notebooks or simple scripts, for occasional projects. Non-expiring traffic and clear dashboards matter more to them than advanced features. Documentation of method matters too, because results get presented and questioned.
Marketers and SEO specialists
They use residential proxies mainly in browsers: checking ads, landing pages, local search results and competitors' sites from specific places. City targeting and a browser extension are their key features. Usage is light but location accuracy is critical.
Security and trust teams
They investigate phishing pages, malicious ads, fraud and abuse, which often hide from corporate and datacenter IPs. They need residential exits in the locations where victims are, isolated browsers, and careful evidence collection. See Geonode for cybersecurity research.
QA and product teams
They check localisation, regional pricing and third-party integrations in each market. Sticky sessions per test run and country targeting cover most needs. See Geonode for localization testing.
If several of these roles share one account, sub-users keep their usage separate and visible.
Checking geo accuracy at scale
For geo-sensitive projects, a one-off spot check isn't enough. Build accuracy checks into the job.
- Log the exit IP for a sample of requests (for example, one in every hundred) by calling an IP echo endpoint through the same session.
- Look up each logged IP in two geolocation databases and record country, region and city.
- Compare with the requested target. Calculate the share of exits that match at each level.
- Check the target's own view. For a sample of pages, record the location the site itself displays or implies (a "deliver to" location, local currency, local listings).
- Alert on drift. If the match rate drops, investigate before trusting the data.
A typical result is near-perfect country accuracy, high state accuracy and lower city accuracy, with the target's own view sometimes disagreeing with all of them. Knowing those numbers lets you state your method's limits honestly.
Keeping records for compliance
If your organisation needs to show how data was collected, keep these records for each project:
- The provider, product and plan used, and the provider's sourcing statement at the time.
- The targets, dates and frequency of collection.
- Proxy configuration: targeting, session settings and request rates.
- What data was collected and why, and how personal data was handled.
- Robots.txt and terms checks, and any opt-outs respected.
This takes little effort when you set up a project and saves a great deal when someone asks questions later. See ethical web scraping.
Residential proxies for small businesses
Small businesses often assume residential proxies are an enterprise tool. They're not. A few common small-business uses, with what they typically need:
- A local service business checking its search visibility in nearby towns: a small residential balance with city targeting, used a few times a month through a browser extension. See Geonode for local SEO.
- An online shop watching competitors' prices: a few GB a month, HTML-only, rotating sessions. See Geonode for price monitoring.
- A brand checking for counterfeit listings on marketplaces in other countries: occasional sticky sessions in the relevant markets, with screenshots for evidence. See Geonode for brand protection.
- A small agency verifying client ads in different regions: city-targeted sessions in a real browser with images on. See Geonode for ad verification.
In each case the volume is small, so the deciding factors are ease of use, location accuracy and whether traffic expires. A pay-as-you-go plan with non-expiring traffic usually fits best, and the total cost is often a few dollars a month. The skills transfer as the business grows: the same measurement and routing habits that keep a small plan cheap keep a large one under control.
The short version
If you skimmed to the end, here's everything that matters about residential proxies in one list:
- Residential proxies route your traffic through real consumer connections, which websites trust more than datacenter IPs.
- Use them for protected targets, location-specific content and high-diversity scraping. Use datacenter proxies wherever they work, and ISP proxies when you need a permanent IP.
- Rotate per request for independent pages, use sticky sessions for flows, and expect occasional early IP changes.
- Target the broadest location that gives correct results, and verify on the target itself.
- Most of your cost is determined by how you fetch: HTML or JSON beats full pages, and blocked assets save a fortune.
- Measure success on content, latency at p95, bytes per success and cost per 1,000 successes, per target.
- Choose providers who can explain their sourcing, and keep a backup provider warm.
- Keep credentials in a secrets store, use sub-users with traffic limits for each project, and review your costs and success rates every single month.
- Respect the sites you collect from and the people whose connections you use: polite rates, minimal data, and no abusive uses.
Get those right and almost any reputable residential provider will serve you well, because most of the difference between a good and a bad residential setup is in how it's used rather than whose network it runs on. If you want a flexible place to begin, Geonode's residential proxies offer non-expiring traffic with country, state, city and ASN targeting, which makes the testing steps in this guide cheap to run. Then compare at least one alternative from our best residential proxies list before you scale up.
How residential pools behave over a day
Residential networks are made of real people's devices, so their size and speed follow human routines:
- Evenings and weekends in a country often have more devices online.
- Night-time in a region can mean fewer exits and more reuse.
- Mobile-heavy pools fluctuate as phones charge overnight on Wi-Fi.
If you run large jobs, test at the hours you'll actually run, and spread work across time zones when you can. A job that runs perfectly at 9 p.m. local time can struggle at 4 a.m.
Residential proxy health metrics to monitor
| Metric | Healthy sign | Warning sign |
|---|---|---|
| Success rate per target | Stable week to week | Sudden drops |
| Unique IPs per 1,000 requests | Mostly unique | Many repeats |
| p95 latency | Consistent | Rising steadily |
| Session hold time | Matches expectations | Sessions dropping early |
| Bytes per success | Stable | Rising (heavier pages or more retries) |
Set alerts on these. Pool quality can change without notice, and early detection saves money.
Residential proxies in browsers and antidetect tools
Not every residential proxy user writes code. Many use them through a browser for manual checks, or through antidetect browsers for managing separate profiles.
In a normal browser
For occasional checks (how does this ad, price or search result look in Germany?), a proxy extension is the easiest route. You select a country, the extension routes the browser through a residential exit, and you browse normally. Remember that cookies and logged-in sessions in your normal browser profile travel with you, so use a separate profile or a private window for clean results. Some providers, including Geonode, offer their own Chrome extensions. See browser proxy settings and using Geonode in Chrome.
In antidetect browsers
Antidetect browsers create many isolated profiles, each with its own cookies, storage and fingerprint, and each can have its own proxy. For residential proxies, use a sticky session per profile with a long lifetime, and match the profile's timezone and language to the exit country. If the profile represents a long-lived account, consider a static ISP proxy instead, because residential sessions eventually change IP. Geonode lists integrations with AdsPower, Dolphin{anty}, GoLogin, MoreLogin and Incogniton. See antidetect browser proxies and Geonode with antidetect browsers.
On phones
Phones can use a proxy through Wi-Fi settings (HTTP proxies) or through apps. Mobile apps don't always respect system proxy settings. See proxy setup on iPhone and Android.
Shared pools and IP reputation
Rotating residential pools are shared: the IP you get now may have been used by another customer an hour ago, on the same site or a different one. That has practical consequences.
- You inherit some reputation. If a previous user triggered a site's defences, the IP may face extra checks for a while. Rotation gets you away from it quickly.
- Your behaviour affects others. Aggressive scraping on a popular target degrades the pool for everyone using that provider on that target, including you tomorrow.
- Providers manage this actively. Good providers track per-target health, rest IPs that are getting blocked, and restrict abusive customers. Ask how a provider handles it.
- Popular targets are harder. The sites everyone scrapes (major marketplaces, search engines, social platforms) see the most proxy traffic and are the most defensive. Expect lower success there than on niche targets, whichever provider you use.
The practical habits are the same as always: rotate on blocks, keep per-IP rates low, and don't treat a residential pool as an infinite resource. See IP reputation and proxies.
The other side: sharing bandwidth as a peer
It's worth understanding the experience of the people whose devices make residential networks possible.
On reputable networks, a person installs an app or agrees to an SDK prompt that clearly explains bandwidth sharing, and in exchange gets payment, credits, premium features or an ad-free app. The software typically limits how much bandwidth is used, runs mainly when the device is idle or charging, and avoids mobile data unless allowed. The person can opt out at any time.
On bad networks, none of that is true: consent is buried or absent, the person doesn't know their connection is used, and sometimes the device is infected with malware.
Why it matters to buyers:
- Consented peers stay online longer and are less likely to be blocked than devices in a known botnet.
- Responsible use protects peers. Abuse through a residential IP can lead to that household's IP being blocked on sites they use.
- Your reputation is linked to your provider's. If your provider is exposed for unethical sourcing, your organisation's name may come up too.
That's why we recommend asking every residential provider how its peers are recruited and paid. Geonode, for example, states that its residential IPs come from opt-in partners. See how proxy providers source IPs.
Picking a session strategy by site type
| Site type | Rotation | Session length | Notes |
|---|---|---|---|
| Large marketplace, product pages | Per request | n/a | Content checks for blocks; HTML or JSON only |
| Retailer with store or ZIP selector | Sticky | 5 to 15 minutes | Set location once per session, then fetch a batch |
| Search engine | Per query | n/a | Low rates; location parameters; consider an API |
| Travel search | Sticky | 10 to 20 minutes | One session per search flow |
| Classifieds and listings | Per request | n/a | Sticky only for pagination |
| Social platform, public pages | Per request | n/a | Respect platform rules; avoid logged-in rotation |
| Logged-in dashboard you own | Static IP | Permanent | Use ISP proxies or whitelisted IPs |
| Ad and landing page checks | Sticky | Length of the redirect chain | Real browser, images on |
Tuning residential proxy performance
When residential jobs feel slow, these adjustments usually help more than switching providers.
- Shorten the first hop. Run your workers near the provider's gateway region, or choose the gateway closest to your servers if the provider offers several.
- Pick exits near the target. For a site hosted in the US, US exits are faster than distant ones, even if you don't need location-specific content.
- Broaden targeting. City targeting narrows the pool; a broader target offers more fast peers.
- Use sensible timeouts. Long enough for honest slow responses, short enough that a dead peer doesn't hold a worker. Then retry with a new IP.
- Increase concurrency, not speed. Throughput is concurrency divided by request time. Within each target's tolerance, more parallel requests beat a faster proxy.
- Reuse sessions for flows, but not forever. A connection to a fast peer is worth keeping for a few requests on the same site.
- Fetch less. Smaller responses arrive faster as well as costing less.
When residential proxies are the wrong tool
Residential proxies are versatile, but they're not always the answer.
- Your own infrastructure. Testing your own sites and APIs doesn't need residential trust; datacenter IPs or a VPN in each region are cheaper.
- Bulk downloads. Large files and media through residential peers are expensive and unfair to peers.
- Permanent identities. Use ISP proxies when an account or integration must always see the same IP.
- Lenient targets. If datacenter IPs work, use them.
- Hard targets with tiny volume. A scraping API can be cheaper once you count engineering time.
- Anything abusive. Credential stuffing, spam, fraud and harassment are prohibited by reputable providers and illegal in many places.
Where residential proxies are heading
A few trends are shaping the next few years of residential proxies.
- Sourcing scrutiny keeps rising. After botnet takedowns and public warnings, expect buyers, platforms and regulators to ask more questions about consent and compensation.
- Bundling continues. Providers increasingly sell proxies with unblockers, scraping APIs, search APIs and datasets, and price them as alternatives.
- AI changes demand. AI agents and training pipelines increase demand for web access, while websites tighten rules for automated traffic and publish AI-specific preferences.
- Detection gets smarter. Websites lean more on fingerprints and behaviour, which makes good client configuration as important as good IPs.
- Prices stay competitive. Per-GB prices have fallen for years; at volume, flat-rate residential plans are becoming more common.
The fundamentals in this guide won't change: test on real targets, choose the right proxy type per target, fetch less, and buy from providers who can explain where their IPs come from.
Residential vs the alternatives, one more time
If you've read this far and still aren't sure whether you need residential proxies, use this rule of thumb:
- If datacenter IPs work on your target, use them and save money. See cheap proxies.
- If you need the same IP for days, use ISP proxies.
- If residential IPs are still blocked, look at fingerprints and behaviour first, then consider mobile proxies or a web unblocker.
- Otherwise, rotating residential is the right tool, and our best residential proxies guide will help you choose a provider.
For the full landscape across every proxy type, see the best proxies guide.
Scaling residential proxy jobs
A script that works on 1,000 pages often falls apart at 1,000,000. These are the practices that keep residential jobs reliable and affordable as they grow.
Budget per domain, not per job
Give every target domain its own limits: maximum concurrent requests, maximum requests per minute, and a daily bandwidth budget. A single misbehaving domain then can't consume the whole plan, and you stay polite to each site.
Queue work, don't loop over it
Put URLs in a queue (a database table, Redis, or a message queue) and let workers pull from it. Workers record the outcome of each URL: success, retryable failure or permanent failure. That makes jobs resumable after crashes, lets you add workers without code changes, and gives you clean success-rate data.
Separate retry queues
Failed URLs go into a retry queue with a delay that grows with each attempt. Retry with a new IP each time and cap total attempts. Without this, retry storms burn bandwidth and hammer targets.
Detect blocks properly
Treat block pages as failures even when the status code is 200. Look for CAPTCHA markers, missing expected elements, or unusually small responses. Count blocks per domain per hour and slow down automatically when they rise.
Adapt concurrency
Start each domain at a modest concurrency and increase while success stays high; decrease when blocks or errors rise. This "slow start" approach finds each site's tolerance without manual tuning.
Spread over time and geography
Residential pools are bigger at some hours than others, and targets are busier at some hours too. For big crawls, spread work across the day. Where the target allows, spread across several countries rather than concentrating on one.
Monitor the right numbers
Per domain: success rate, blocks per 1,000 requests, median and p95 latency, bytes per success, and retries per success. Per provider: error rates by type (timeouts, 407s, connection resets). Alert on sudden changes rather than absolute values.
Keep a fallback
Configure a second provider in your proxy helper so you can shift a domain, or everything, if your primary has problems. Test the fallback monthly with a small amount of traffic.
Mind the data you keep
At scale, storage and data protection become real issues. Store only the fields you need, drop personal data you didn't intend to collect, and set retention periods.
Troubleshooting residential proxies
| Symptom | Likely cause | What to try |
|---|---|---|
| 407 Proxy Authentication Required | Wrong credentials, wrong username syntax, or IP not whitelisted | Re-copy credentials from the dashboard; check targeting syntax; check whitelist |
| Connection timeouts | Slow or offline peer, overloaded narrow targeting | Increase timeout moderately; retry with a new session; broaden targeting |
| Frequent 403s or CAPTCHAs | Target blocking based on fingerprint, rate or reputation | Lower rate; fix client fingerprint; rotate on block; try a browser |
| Pages load but data missing | Content rendered by JavaScript, or a block page served as 200 | Check for JSON endpoints; use a browser; add content checks |
| Wrong country or city content | Geo mismatch between provider and target databases, or site uses other location signals | Verify on the target; set the site's own location; match language and timezone |
| Sticky session changes IP | Peer went offline or lifetime expired | Shorter flows; detect IP change and restart; use ISP proxies for permanence |
| Usage much higher than expected | Heavy pages, retries, assets in browsers | Measure bytes per success; block assets; fix retries |
| Same IPs repeating | Narrow targeting or small live pool at that hour | Broaden targeting; spread over time; check with provider |
| Works in curl, fails in code | Different headers, TLS fingerprint or proxy format | Compare requests; check URL encoding of special characters in passwords |
| Slow everything | Client far from gateway; peers far from target | Use a nearer gateway region; target exits near the site |
A frequent hidden cause of 407 errors is special characters in passwords. If your password contains @, : or /, URL-encode it in proxy URLs. See common proxy errors and how to check if a proxy works.
The legal landscape, briefly
Residential proxies are legal to buy and use in most countries. The legal questions come from what you do through them. This is a general overview, not legal advice.
Data protection
If you collect personal data (anything that identifies a person), data protection laws apply in many jurisdictions, including GDPR in Europe and state laws such as CCPA in California. Key principles: have a lawful basis, collect the minimum, secure it, respect rights requests, and don't keep it longer than necessary.
Computer misuse laws
Laws such as the US Computer Fraud and Abuse Act prohibit unauthorised access to computer systems. US courts have generally treated scraping of publicly accessible pages differently from accessing systems behind logins or after being explicitly blocked, but the details depend on facts and jurisdiction. Circumventing technical barriers, using others' credentials or ignoring cease-and-desist letters increases risk.
Contracts and terms of service
Website terms often prohibit automated access. Breaching terms is usually a civil matter, but companies do sue, especially when the scraper agreed to the terms by creating an account. Logged-out collection of public pages and logged-in collection carry different risks.
Intellectual property
Collecting facts (prices, availability) is different from republishing creative content (articles, photos, reviews). Copyright and database rights may apply to what you do with collected content.
The proxy network itself
Buying access to a network built on infected devices exposes you to ethical and potentially legal problems. Provider due diligence is part of compliance.
If your project is commercial, large, involves personal data or targets a company known to litigate, get legal advice. See are proxies legal? and ethical web scraping.
Why sourcing became a buying criterion
For years, buyers compared residential proxies on price, pool size and success rate, and sourcing was a footnote. Two enforcement stories changed that:
- In 2024, US authorities and international partners dismantled 911 S5, a botnet of infected Windows computers that had been sold for years as a residential proxy service.
- In June 2025, the FBI warned that BADBOX 2.0, a botnet of millions of infected devices such as cheap TV streaming boxes and digital picture frames, was feeding residential proxy services. The FBI's public service announcement is short and worth reading.
Why this matters to you as a buyer:
- Your traffic may exit through a stranger's compromised device if you buy from a network built on malware. That's an ethical problem and, depending on what you do, potentially a legal one.
- Those IPs get burned faster. Networks known to include botnet exits attract blocklisting, which drags down success rates for everyone using them.
- Your provider can disappear overnight when a network is taken down, along with any prepaid balance.
The fix is simple: ask how peers are recruited and paid, whether consent is explicit and separate from other terms, and whether the provider checks its own customers. Providers with good answers usually publish them. See ethically sourced proxies, how proxy providers source their IPs and the warning signs in proxy provider red flags.
How websites treat residential traffic
It helps to see residential proxies from the website's side. A typical bot-protection system asks a series of questions about every visitor, and the IP type is only the first.
- What kind of network is this? Residential and mobile networks pass this check easily; hosting ranges don't. This is where residential proxies earn their price.
- Has this IP or subnet behaved badly recently? Residential IPs are shared over time between many proxy customers. If a previous user abused an IP on this site, it may carry a penalty for a while. Rotation helps.
- How fast is this IP sending requests? Rate limits apply to residential IPs too. Rotation spreads load; pacing keeps each IP well-behaved.
- Does the client look like a real browser? TLS fingerprints, headers and JavaScript checks are independent of the IP. A script with a bot-like fingerprint is suspicious from any network.
- Does everything match? A US residential IP with a browser set to Russian language and a Singapore timezone looks odd. Consistency matters.
- Does the behaviour look human? Navigation paths, timing and interaction count, especially for browser-based access.
- Is there account or session history? Cookies and logged-in history build trust; new sessions start neutral.
Residential proxies answer question 1 well and help with 2 and 3. Everything else is up to your client and your behaviour. That's why the best results come from combining good proxies with a realistic client, consistent settings and polite pacing. See browser fingerprinting and proxies and avoiding IP bans when scraping.
Your first hour with residential proxies
If you've just bought your first residential plan, this hour gets you from credentials to confident.
Minutes 0 to 10: Generate an endpoint
In your provider's dashboard, find the proxy configuration or endpoint generator. Choose a country, rotating sessions, and the host:port:username:password format or a full proxy URL. Copy one endpoint.
Minutes 10 to 20: Confirm it works
From a terminal:
curl -x "http://USERNAME:PASSWORD@HOST:PORT" https://api.ipify.orgRun it three times. With rotation, you should see different IPs. Look one up in an IP location service and confirm the country. If you get a 407, re-check credentials and username syntax. See cURL proxy.
Minutes 20 to 30: Try a sticky session
Generate a sticky endpoint (or add a session parameter), run the same command several times, and confirm the IP stays the same. Change the session ID and confirm it changes.
Minutes 30 to 45: Try your real target
Request one of your real target pages through the proxy with your real client. Check that the content is what you expect, not a block page. Note the response size: that's your bandwidth cost per page.
Minutes 45 to 60: Write it down
Record what worked: endpoint format, targeting syntax, session syntax, response size per page, and any errors. Put credentials in environment variables and build your proxy helper. You're ready to write the real job, with the patterns from the code section above.
Providers with an endpoint generator and a browser extension make this hour easier. Geonode's dashboard, for example, generates ready-to-paste endpoints, and its Chrome extension lets you check a target visually through a residential exit before writing any code. See using Geonode in Chrome.
A sample provider comparison
Here's what a fair comparison of two residential providers looks like in practice, for a team monitoring prices on four retailers in the US and UK.
The plan
- 500 requests per retailer per provider, interleaved, over two days, at production hours.
- HTML via an HTTP client, content verified by checking for a price element.
- 50 IP echo requests per country per provider for diversity and geo checks.
- Ten sticky sessions of 15 minutes per provider.
The results (illustrative)
| Metric | Provider A | Provider B |
|---|---|---|
| Success rate, retailer 1 (US) | 97% | 95% |
| Success rate, retailer 2 (US) | 91% | 96% |
| Success rate, retailer 3 (UK) | 94% | 89% |
| Success rate, retailer 4 (UK) | 98% | 98% |
| Median latency | 1.4 s | 1.1 s |
| p95 latency | 4.8 s | 6.2 s |
| Unique IPs per 50 (US / UK) | 50 / 49 | 50 / 46 |
| Sticky sessions held 15 minutes | 9 of 10 | 8 of 10 |
| Cost per 1,000 successes (blended) | $0.31 | $0.27 |
The decision
Neither provider wins everything. Provider B is cheaper and faster on median, but weaker on retailer 3 and slower at p95. The team chooses B as primary for the US retailers and A as primary for retailer 3, keeping each as the other's backup. A split like this is common and costs nothing extra if both providers offer flexible plans.
The lesson: compare per target and per metric, not on a single overall score.
Residential proxies for organisations
When residential proxies move from one developer's script to a team's infrastructure, a few governance habits prevent problems.
- An owner. Someone is responsible for providers, budgets, credentials and incidents.
- An approved-use policy. Write down what the organisation uses proxies for and what's off-limits (personal data beyond what's needed, logged-in access to third-party accounts, prohibited targets).
- Vendor due diligence. Keep a record of each provider's sourcing statement, data processing terms and security practices.
- Credential management. Sub-users per project, stored in a secrets manager, rotated on staff changes.
- Monitoring and budgets. Per-project usage dashboards, alerts and monthly reviews.
- Data handling. Retention periods and access controls for collected data.
- Incident process. What to do if credentials leak, a provider has an outage, or a website complains.
None of this is heavy. A one-page policy and a shared dashboard cover most of it, and they make conversations with legal, security and finance much easier.
Residential, ISP or mobile? A decision guide
Work through these questions in order. Stop at the first "yes".
- Does the target work reliably with datacenter IPs at your request rate? Use datacenter proxies. They're far cheaper.
- Do you need the same IP for days or weeks (an account, a whitelisted integration, a long-running session)? Use ISP proxies.
- Do you need many different IPs, location targeting, or high trust on a protected site? Use rotating residential proxies, with sticky sessions for stateful flows.
- Are residential IPs still blocked after you've fixed fingerprints, rates and behaviour? Try mobile proxies for that target, or a web unblocker.
- Is the target so hard or the volume so low that engineering time dominates? Use a scraping API.
Most real projects end up using two or three of these for different targets. That's normal and usually the cheapest overall.
Residential proxy glossary
| Term | Meaning |
|---|---|
| Peer / exit node | The real device whose IP the website sees. |
| Gateway / super proxy | The provider's server you connect to, which routes you to peers. |
| Backconnect | The general pattern of connecting to one gateway and exiting through many IPs. See backconnect proxies. |
| Rotating | A new peer per request or connection. |
| Sticky session | The same peer for a set time or until the session ID changes. |
| Session ID | The identifier, usually in the username, that pins a sticky session. |
| Session lifetime | How long a sticky session lasts before rotating. |
| Geo-targeting | Choosing country, state, city or ZIP for exits. |
| ASN targeting | Choosing exits on a specific ISP's network. |
| Pool | The set of peers available for your targeting. |
| Live pool | The peers online right now, as opposed to a cumulative count. |
| IP churn | The constant change of IPs as peers join, leave and get new addresses. |
| SDK sourcing | Recruiting peers through software kits embedded in apps. |
| Opt-in | Explicit consent from device owners to share bandwidth. |
| CGNAT | Carrier-grade NAT, where many users share one public IP (common on mobile). |
| Per-GB billing | Paying for traffic volume. |
| Non-expiring traffic | Purchased GB that don't disappear at the end of a period. |
| Unblocker | A managed layer on top of proxies that handles challenges and retries. |
| Whitelisting | Authenticating by your server's IP instead of a username and password. |
For the full list, see the proxy glossary.
More residential proxy questions, answered
How many residential IPs will I get?
With rotating residential proxies you don't buy a number of IPs. Each request or session draws from the live pool for your targeting. In a large country with broad targeting, you can make many thousands of requests and see almost no repeats. In a small city, you'll see repeats sooner.
Can I choose a specific IP and come back to it tomorrow?
Not reliably. Sticky sessions keep an IP for a limited time, and the peer may be offline or have a new address tomorrow. For a permanent IP, use ISP proxies.
Why does my traffic usage not match my page sizes?
Providers usually count upload and download, headers and TLS overhead, and failed attempts. Browsers also load far more than the HTML. Measure through your provider's statistics, not just page sizes.
Do residential proxies support UDP?
Most HTTP-oriented residential products don't. Some SOCKS5 offerings support UDP, but it's uncommon and should be tested. See SOCKS5 proxies.
Can I use residential proxies for streaming or downloading large files?
Technically sometimes, but it's expensive per GB, often against provider terms, and unfair to the peers whose connections you're using. Residential proxies are designed for requests, not bulk downloads.
Is it safe to log in to my own accounts through a residential proxy?
Over HTTPS, a reputable provider's proxy can't read your traffic content. But logging in from a random residential IP can trigger the site's security checks, since it looks like a login from a new location. For accounts, use a consistent static IP.
Why do some sites still show me CAPTCHAs?
Because IP type is only one signal. Fingerprints, behaviour, rate and IP history all count. See CAPTCHAs and proxies.
What's the difference between residential and "static residential"?
Residential usually means rotating access to real consumer devices. Static residential (ISP proxies) means fixed IPs registered to consumer ISPs but hosted on servers. See ISP vs residential proxies.
Do I need city targeting for SEO?
For local SEO and map results, yes, or at least the nearest available city plus the search engine's location parameters. For national rankings, country targeting is usually enough.
How do I stop a script from using all my traffic?
Use sub-users with traffic caps, request ceilings in code, and alerts on unusual usage.
Can I resell residential proxies?
Some providers have reseller programmes; Geonode's dashboard, for example, includes a reseller section. Reselling without permission usually breaches terms. See how to become a proxy reseller.
How do I know a residential provider isn't using a botnet?
You can't know for certain, but specific, published sourcing details, a long track record, customer checks and reasonable prices are good signs. Vague answers and prices far below the market are bad ones. See ethically sourced proxies.
The residential proxy buying checklist
Before you buy:
- Targets listed, with whether each truly needs residential IPs (test datacenter first)
- Locations and the targeting level each needs
- Session pattern per workflow, and the session length you need
- Estimated GB per month from real page sizes, plus 20 to 30% overhead
- Usage pattern: steady (subscription) or uneven (non-expiring pay-as-you-go)
- Two or three providers shortlisted on coverage, targeting, sessions, protocols, expiry, sourcing, dashboard and support
While testing:
- At least 500 requests per target per provider, interleaved, at production hours
- Content-based success checks
- Median and p95 latency, bytes per success, cost per 1,000 successes
- IP diversity and geo accuracy samples
- Sticky session hold tests
After buying:
- Proxy helper with credentials in environment variables
- Per-domain limits, queues, retry queues and block detection
- Monitoring and alerts
- Monthly cost review, quarterly re-test, backup provider
If you want one place to start, Geonode offers residential traffic that doesn't expire, with country, state, city and ASN targeting and sticky sessions of up to 24 hours. Run the checklist against it and at least one alternative, and let your results decide. For provider comparisons, see best residential proxies and residential proxy providers compared.
FAQ
Are residential proxies legal?
Yes, using residential proxies is legal in most jurisdictions, provided the IPs were sourced with consent and you use them for lawful purposes. Scraping personal data or breaching a site's terms can create legal risk regardless of the proxy type.
Are residential proxies better than datacenter proxies?
For avoiding blocks, yes. For speed and price, no. The best choice depends on your target. See residential vs datacenter proxies.
Why are residential proxies slow sometimes?
Traffic passes through a real consumer device and its home connection, which adds latency and variability. Choosing exit nodes in the same region as the target helps.
Can I get a dedicated residential IP?
Yes, that's what static residential (ISP) proxies provide. Rotating residential pools are shared by design.
What's the cheapest way to buy residential proxies?
Pay-as-you-go plans with non-expiring traffic for occasional use, and volume plans once you know your usage. See best cheap residential proxies.
Do residential proxies work with SOCKS5?
Many providers support SOCKS5 on their residential gateways, though HTTP(S) is more universal. See SOCKS5 proxies.
Editorial note: Proxy providers change their pools, features and prices often, so treat any figures here as typical ranges at the time of writing and confirm current terms with the provider before you buy.