TL;DR
- A residential proxy routes your traffic through a real ISP-assigned IP address, so an automated request looks like ordinary consumer traffic instead of a data center.
- Residential, datacenter, mobile, and ISP proxies solve overlapping problems in different ways – this guide breaks down when each one is worth the cost.
- Get a grounded rundown of use cases, legal status, and pricing for residential proxies, without the vendor sales pitch.
- Learn how to wire a residential proxy into your own scraping or automation stack, including Browserless's built-in option.
Introduction
If a site blocks your datacenter IPs on sight, a residential proxy is usually one of the first solutions to think of.
In this guide, you'll learn what actually makes an IP "residential," how it differs from datacenter, mobile, and ISP proxies, and when the extra cost is worth paying.
You'll also get insights into pricing and a walkthrough of how you can use a residential proxy in a real scraping or automation project.
What is a residential proxy?
A residential proxy is an IP address that an ISP has assigned to an actual residential device – a home router, a phone on a mobile data plan, or a smart-home gadget, for example – and that you route your web requests through instead of using your own IP directly. The site on the other end sees the request as if it came from someone's home internet connection, because it did.
A proxy server sits between your client and the destination site, forwarding requests and returning responses on your behalf.
A datacenter proxy does the same job using an IP registered to a hosting provider. Those IP ranges are well documented, easy to flag, and often blocked outright by sites that care about bot traffic.
A residential IP carries none of that baggage. It belongs to a real ISP subscriber, so residential proxy providers often charge several times more for it than for datacenter bandwidth.
How does a residential proxy work?
Your request first reaches the proxy provider's gateway, which assigns it an IP address from a pool of residential connections. Many of these pools come from real devices whose owners opted in through an SDK bundled into a free app or a peer-to-peer network, in exchange for a payment or a free service.
The target site receives the request from that residential IP and responds to the gateway, which relays the response back to you.
Two session behaviors sit on top of this basic flow: an IP that stays fixed for as long as you need it, and one that changes on a set schedule. Which one you want depends on the job.
Static, rotating, and sticky residential proxies
Residential proxies also differ in how long you keep the same IP. A static residential proxy holds one IP across sessions, which suits logins, account management, and shopping cart flows where switching IPs mid-task looks suspicious.
A rotating proxy assigns a new IP on every request or at a fixed interval, which is a better fit if you need high-volume scraping and distributed data collection – a single fixed identity isn't as good in this scenario.
A sticky session sits between the two: it holds one IP for the life of a single browsing session, then rotates to a new one on the next session.
It gives you the continuity a login flow needs without permanently tying up one IP, as a fully static proxy does.
For a deeper look at configuring session behavior against real anti-bot systems, see how residential proxies pair with browser automation.
Residential proxies vs. other types of proxies
Residential proxies aren't the only proxy option when it comes to avoiding bot detection. The table below compares the four main proxy types based on where the IP comes from, how easily a site can detect it, what it typically costs, and what it does best.
| Proxy type | IP source | Detection risk | Typical cost | Best for |
|---|---|---|---|---|
| Residential | ISP-assigned home IP | Low | Highest (per GB) | Sites with active anti-bot defenses |
| Datacenter | Hosting provider IP block | Higher | Lowest | High-volume, low-scrutiny targets |
| Mobile | Carrier-assigned cellular IP | Lowest | High | Mobile-specific testing, ad verification |
| ISP | ISP-registered but hosted on server infrastructure | Low to moderate | Moderate | A middle ground between residential and datacenter |
A mobile proxy routes through a carrier-assigned cellular IP. Carriers put thousands of subscribers behind a small number of shared IPs (carrier-grade NAT), so sites can't block a mobile IP without blocking real customers, which is why detection risk is lowest and the price is close to residential.
An ISP proxy occupies the middle ground: the IP is registered to a real internet service provider, just like a residential IP, but it runs on server-grade hardware in a data center rather than on someone's actual home connection.
It gains much of a residential IP's trust along with a datacenter proxy's speed and uptime, at a price between the two. The catch is availability. ISP proxy pools are smaller than residential or datacenter pools, since providers need genuine ISP cooperation to register the IP blocks in the first place, so there is less coverage for users in smaller countries and cities.
Datacenter proxies are cheaper, faster, and a solid choice for a site without meaningful bot defenses. Save the residential premium for targets that actually push back against automated traffic.
Why use a residential proxy? 6 common use cases
Residential proxies are the best option against sites that actively try to tell bots and humans apart. Here are some of the situations you might come up against:
- Web scraping protected sites. Retailers, ticketing platforms, airlines, and social networks increasingly run anti-scraping bot defenses that block datacenter ranges outright, so a residential IP is usually the minimum requirement before any other anti-detection work pays off.
- Ad verification. Confirming that an ad displays correctly, in the right language, and to the right audience in a given region requires you to use requests that genuinely originate from that region, which a residential IP can deliver.
- Price and market research. Retail and travel sites serve different prices by location, and a residential proxy in the target market gets you the price a local shopper would actually see.
- Accessing geo-restricted content. Streaming catalogs, regional news, and location-locked services check the requesting IP's location before serving content, and a residential IP in that region gets you past the check.
- Social media account management. Many social platforms will flag if you manage several accounts from one datacenter IP. Spread legitimate multi-account work (agencies, brand accounts) across residential IPs to make it look like ordinary usage – check the platform's terms first, since many restrict automation outright.
- SEO and rank monitoring. Search results vary by location, so you need a request that originates from the market you're tracking for accurate local rank tracking.
Each of these has the same root cause: the target site can't distinguish the request from a genuine local visitor.
How much does a residential proxy cost?
Third-party residential proxy providers generally price by one of two models: pay-per-GB of bandwidth consumed, typically a few dollars per gigabyte, or a flat monthly plan with a bandwidth cap.
The price climbs with pool size, city-level targeting, sticky-session support, and dedicated or static IPs, which all narrow the available inventory a provider has to work with.
Bandwidth adds up fast if you're not paying attention to it. Cutting the amount of data your browser downloads, through techniques like rejecting unnecessary requests and reusing connections, reduces the bill regardless of which provider you use.
You can also proxy only the requests that need it. In our Browser Automation Protocol (BAP), page.proxy() takes a type filter, so you can route only document requests through the residential network while images and scripts load from the instance's own IP. That cuts metered bandwidth without changing what the site sees. BrowserQL's proxy mutation does the same.
There's also a usage-based alternative to running a separate proxy dashboard: bill the proxy as part of the browser session that's already running, rather than buying bandwidth in a different tool entirely – read more on this in the next section.
How to use a residential proxy
Using a residential proxy well has less to do with the proxy itself and more to do with the workflow around it: pick a provider you can trust, decide how long to hold an IP, and make sure the browser behind that IP doesn't still give you away.
Choosing a residential proxy provider
Before signing up with any provider, check the following:
- Confirm the pool size and geographic coverage actually match where you need to appear.
- Ask how the provider sources its IPs and whether device owners gave informed consent, tying back to the legal considerations covered later in this guide.
- Check whether it supports city- or ASN-level targeting if your use case needs that precision, whether sticky sessions are available, and whether pricing is transparent with no hidden bandwidth minimums.
- A free proxy might be OK for a quick test, but production workloads need a provider you can actually rely on.
Run a small test batch against your real target before committing to a plan. The success rate on the site you're scraping tells you far more than a provider's marketing materials, while also surfacing problems like a thin city-level pool or a slow gateway before they show up in production.
Integrating a residential proxy into your automation stack
Once you've picked a provider, integration is usually the same process. Authenticate to the provider's gateway, usually a host and port with a username and password, and pass those credentials through your HTTP client or headless browser's proxy configuration.
Decide upfront whether the job needs a sticky session, for logins and multi-step checkout flows, or per-request rotation, for bulk scraping where each request is independent.
A Puppeteer session pointed at a third-party residential gateway generally looks like this:
import puppeteer from "puppeteer";
const browser = await puppeteer.launch({
args: ["--proxy-server=gateway.example-provider.com:7000"],
});
const page = await browser.newPage();
await page.authenticate({
username: "YOUR_PROXY_USERNAME",
password: "YOUR_PROXY_PASSWORD",
});
await page.goto("https://example.com");
await browser.close();
The --proxy-server flag points Chrome at the gateway, and page.authenticate() handles the credential handshake before the first request goes out. Playwright follows the same shape through its proxy context option instead of a launch argument.
Don't stop at the proxy. A residential IP alone won't help if the browser behind it still exposes navigator.webdriver, ships a default headless viewport, or sends inconsistent headers.
The proxy and the browser have to work together, or the disguise falls apart the moment the site looks past the IP address.
Using Browserless's built-in residential proxy
Browserless includes a residential proxy on every plan, including the free tier, so there's no separate account or bill to reconcile. Add proxy=residential as a query parameter to a REST API call or WebSocket connection you're already making, and Browserless routes that session's traffic through a residential IP:
curl --request POST \
--url "https://production-sfo.browserless.io/content?token=YOUR_API_TOKEN_HERE&proxy=residential&proxyCountry=us" \
--header "Content-Type: application/json" \
--data '{"url": "https://example.com"}' \
--output "page.html"
Add proxyCountry with an ISO 3166 country code to target a specific country, and proxySticky=true to hold the same exit IP for the life of the session.
For sites with real bot defenses, pair the proxy with a stealth route so the browser holds up as well as the IP. The residential IP handles reputation, and /stealth handles the fingerprint:
const browser = await puppeteer.connect({
browserWSEndpoint:
"wss://production-sfo.browserless.io/stealth?token=YOUR_API_TOKEN_HERE&proxy=residential&proxyCountry=us&proxyLocaleMatch=1",
});
proxyLocaleMatch=1 sets the browser's language to match the proxy country, so a US IP doesn't show up with a German Accept-Language header.
Plain REST endpoints like /content and plain Puppeteer or Playwright connections rotate the IP by default; stealth routes, BAP, /unblock, and /scrape are sticky by default (pass proxySticky=false to rotate there), because anti-bot vendors like Akamai and DataDome tie their cookies to the exit IP.
A proxyCity parameter targets a specific city within that country, though it requires a Scale plan (500k+ units per month).
Pricing runs on the same unit system as everything else on Browserless: residential proxy traffic costs 6 units per MB, and a cheaper proxy=datacenter option is available at 2 units per MB for jobs where detection risk is low enough that a datacenter IP will do.
Browserless doesn't offer static residential IPs, only rotating IPs with the option to hold one sticky for a session. If your workflow genuinely needs the same residential IP across multiple separate sessions, bring a third-party static proxy with the externalProxyServer query parameter (for example, externalProxyServer=http://user:pass@host:port, URL-encoded). Using your own proxy requires a paid plan, and it can't be combined with proxy=residential in the same session.
For the full setup across Playwright, Puppeteer, and Browser Automation Protocol, including how to handle session stickiness against specific anti-bot vendors, check out the residential proxies for web automation guide linked earlier.
For more on the feature, read the docs on our Proxies.
Is a residential proxy legal?
Using a residential proxy is generally legal in the US and most other jurisdictions when you're accessing publicly available data and staying within the target site's terms of service.
The Ninth Circuit's ruling in the hiQ Labs v. LinkedIn case found that scraping publicly accessible data doesn't violate the Computer Fraud and Abuse Act, even when a site's terms of service say otherwise, though a terms-of-service violation can still expose you to a civil breach-of-contract claim, a different kind of risk than criminal liability under the CFAA.
Where there are legal questions is when someone pulls data from behind a login without authorization, uses a proxy to commit fraud, or works with a provider that sourced its IP pool without the device owners' informed consent.
Some cheap residential proxy networks get their IPs by bundling proxy software into free VPN apps or browser extensions, so make sure you read the fine print closely enough to know that your connection is not being resold.
Pick a provider that's transparent about how it sources IPs, and don't treat this section as legal advice. If your use case goes beyond the straightforward collection of public data, talk to a lawyer before you build a workflow around it.
Conclusion
A residential proxy is the proxy you will need to get past a site's anti-bot defenses that start blocking datacenter IPs outright, but it's overkill if a site has little to no anti-bot detection.
Match the proxy type to the target – datacenter for high-volume, low-scrutiny jobs, and residential when a site actively fights back – and remember that the proxy is only half the picture. The browser session behind it needs to hold up too.
If you'd rather not stand up a separate proxy service and reconcile a second bill, sign up for Browserless and add proxy=residential to your connection.
Residential proxy FAQs
Can residential proxies be detected?
Yes, though less easily than datacenter traffic. Sophisticated anti-bot vendors track known proxy IP ranges and behavioral patterns, so a residential proxy lowers detection risk rather than eliminating it, especially when it's paired with a browser that still looks automated in every other respect.
How can I get a residential proxy?
Sign up with a third-party residential proxy provider and configure your HTTP client or browser to route through its gateway, or use a service like Browserless that includes a residential proxy option built into the browser sessions you're already running.