Datacenter Proxies vs Residential: What Each One Actually Fixes
A real residential IP with a real Chrome user agent still got 403 from two sites. The IP type was not the constraint. What each type does fix.
Copy this line to your agent to fetch a page that refused your IP.
set up https://monid.ai/SKILL.md and use context.dev /web/scrape/markdown to read a page that returns 403
Every article on this keyword is written by a company that sells both kinds of proxy, so the conclusion is always that you need one of them and probably the expensive one. We do not sell proxies, which lets this guide start from a measurement instead. On 2026-09-01, from an ordinary residential ISP connection with a current Chrome user agent, two sites returned 403. A residential IP is exactly what those articles say fixes that, and it did not. This guide is about what the two proxy types genuinely do, what they do not, and where the actual constraint sits, running through Monid, the OpenRouter for agent tools.
What is the difference between datacenter and residential proxies?
Where the IP address is registered, and nothing else. Everything downstream follows from that one fact.
Datacenter
An IP owned by a hosting provider and registered to a commercial ASN. Cheap, fast, available in enormous blocks, and trivially identifiable as belonging to a server rather than a person. Any site that wants to can download the list of hosting ASNs and treat them differently.
Residential
An IP assigned by a consumer ISP to a household connection. Expensive, slower, usually sold by bandwidth rather than by IP, and indistinguishable at the ASN level from a real customer, because it belongs to one.
The stated logic, and where it breaks
The pitch is that sites block hosting ASNs, so a residential IP looks like a person and gets through. That logic is sound as far as it goes, and it stops at exactly the point where a site checks anything other than the ASN. Which most serious sites now do.
What neither type changes
Your TLS handshake. Your HTTP/2 frame ordering. Your header order and casing. Whether JavaScript executes. Whether the browser has a WebGL context. Whether the request pattern looks human. A proxy changes the address a request comes from and nothing about the request itself, and that distinction is the whole of this article.
📖 See also Do AI Agents Need a Rotating Proxy?
Why did a real residential IP still get blocked?
Because the sites in question were not checking the IP.
The measurement
Four fetches on 2026-09-01, plain curl, from a residential ISP connection, sending a current Chrome user agent string:
| Target | Status | Bytes |
|---|---|---|
g2.com/products/notion/reviews | 403 | 1,704 |
zillow.com/homes/for_sale/ | 403 | 5,816 |
indeed.com/q-software-engineer-jobs.html | 200 | 2,281,912 |
news.ycombinator.com | 200 | 33,592 |
The address was residential. The user agent was correct. Two of the four refused anyway, and the two that refused are the two protected by commercial anti-bot services.
Note also the body sizes on the 403s: 1.7KB and 5.8KB. Those are challenge pages, not errors, which is why a size check is a better tripwire than a status check when you are looking for silent blocking.
What those sites were actually reading
Everything except the IP. A curl request has a TLS fingerprint no browser produces, header ordering no browser produces, and no JavaScript execution at all. Any one of those is sufficient to classify the request, and none of them is affected by which network it arrived from.
The same two URLs, fetched properly
Through a hosted renderer on the same day, both returned real content. The G2 page came back as 16,837 characters of Markdown with the title "The G2 on Notion". The Zillow search came back with 126 listings and prices.
The difference between the failed attempt and the successful one was not the IP address. It was a browser that produces a browser's fingerprint.
What this means for the buying decision
If you are choosing between datacenter and residential proxies to solve blocking, you may be choosing between two things that will not solve it. The honest first step is to determine what your target is actually checking, and the cheap way to do that is to test the same URL through a browser-based fetch before spending anything on IPs. This is the same reasoning as what actually gets through when a scraper is blocked: identify the layer that failed before buying at a different layer.
How do you fetch a page that refuses your IP?
Three steps. The first is free and it is the one that saves the money.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main
Step 1. Find out which layer is refusing you
What it does. Separates an IP problem from a fingerprint problem, which decides everything you do next.
The call. No endpoint, just two requests:
curl -s -o /dev/null -w "%{http_code} %{size_download}\n" \
-A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/152.0.0.0 Safari/537.36" \
"https://your-target.example/page"
What comes back. A 403 with a small body means a challenge, and a challenge from a residential connection means the IP was not the issue. A 200 with the content you expected means you never needed a proxy. A 429 means rate limiting, which is the one problem rotation genuinely solves.
What it costs. Nothing, and it is the step people skip before buying bandwidth.
Step 2. Fetch through a maintained browser
What it does. Supplies the whole request profile, not just the address.
The endpoints. context.dev/web/scrape/markdown for content, context.dev/web/scrape/html when you need the DOM. Both billed per call.
The call.
monid run -p context.dev -e /web/scrape/markdown --query '{"url": "https://www.g2.com/products/notion/reviews"}'
What comes back. On 2026-09-01, for that URL: 16,837 characters of clean Markdown with metadata, from a URL that returned 403 to curl minutes earlier. The Zillow search URL, also 403 to curl, returned 3,462 characters with 126 listings.
What it costs. A fraction of a cent per page. Current figures at monid.ai/tools. The comparison worth making is against bandwidth pricing: residential proxies are sold per gigabyte, and a modern page is often two megabytes, so a per-page price is directly comparable and usually easier to forecast.
Step 3. Assert on content so you notice when this stops working
What it does. Catches the day the challenge page starts arriving with a 200.
The call. No endpoint:
def usable(md: str) -> bool:
if len(md) < 1500: # challenge pages are small
return False
return "Reviews" in md # something only the real page has
What comes back. A block rate rather than a surprise. Both of the 403s above had bodies under 6KB, and a length floor would have caught either without any status inspection at all.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to fetch these 25 URLs as markdown and tell me which ones came back under 2KB, because those are challenge pages not content.Does the proxy's location change what you get back?
Yes, and this is the strongest real reason to care about proxy geography. It has nothing to do with blocking.
What happened on 2026-09-01
The Zillow request asked for zillow.com/homes/for_sale/ with no location specified. It came back titled "Wayne NJ Real Estate", with 126 listings in Wayne, New Jersey.
Nobody asked for New Jersey. The site inferred a location from the exit IP and returned a result set for it. The response was complete, valid and successful, and it answered a question that had not been asked.
Why this matters more than blocking
A blocked request is loud. It returns 403, you notice, you fix it. A geo-localised result set is silent: it returns 200 with real data in the right shape, and if you are aggregating across many requests you get a dataset whose composition was determined by wherever your exits happened to be that day.
Prices, availability, search rankings, language, currency, tax display and which products even appear are all commonly location-dependent, which is why what a property listing actually carries starts from the search parameters rather than the record. So the practical rule is to pin location explicitly when the data is location-sensitive, and treat any result set you did not pin as being about an unknown place.
The check that costs nothing
Look at what came back before you trust it. In the Zillow case the location was in the page title, which is often true. If your extracted records carry a place, region or currency field, assert that it matches what you intended rather than assuming.
Where geography is a genuine requirement
Search results, ecommerce pricing, streaming catalogues, ad delivery, and anything where the answer legitimately differs by market. In those cases you need controlled exit geography, and that is a real reason to pay for proxies. It is a different reason from the one this keyword is usually sold on.
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
context.dev/web/scrape/markdown | Fetch and convert | A URL | Clean Markdown plus metadata | You want the content | Per call |
context.dev/web/scrape/html | Fetch and return DOM | A URL | Full rendered HTML | You need your own selectors | Per call |
context.dev/web/search | Search, optionally scrape | A query | Results with optional page content | You do not have URLs yet | Per result |
context.dev/brand/ai/product | Structured product fields | A URL | Typed product object | Ecommerce pages | Per call |
Every row was verified with monid inspect on 2026-09-01. The table gives billing shape rather than figures; shape drives design and current numbers live on monid.ai/tools.
None of these rows is a proxy, which is the point. They are fetches that already include whatever network and browser profile the operator maintains, priced per page rather than per gigabyte. If your problem is "I need this page and my requests get refused", that is a different purchase from "I need controlled IPs".
When do you genuinely need to buy proxies?
Four cases, and they are legitimate.
You need specific geography. Per the section above. If your question is what a shopper in Munich sees, you need an exit in Munich, and no amount of fingerprint work substitutes.
You are rate limited rather than blocked. A 429 is a per-IP counter, and spreading requests across addresses is exactly the right fix. This is the case where rotation earns its keep, and it is covered properly in the rotating proxy guide. The same per-IP counter logic shows up in job scraping per board.
You already run your own browser stack. If you have solved the fingerprint problem and are operating Playwright at scale, proxies are the remaining piece and buying them is straightforward. Datacenter for unprotected targets, residential for the ones that filter ASNs.
Volume makes bandwidth cheaper than per-page. At sufficient scale, per-gigabyte pricing beats per-page pricing. Work out where that crossover sits for your actual page weights rather than assuming it, because a two-megabyte page changes the arithmetic considerably.
And the disclosure: we do not sell proxies, so this article has an obvious bias in the other direction, and you should read the four cases above as the part where that bias is working against us. The measurement at the top stands on its own: two sites refused a genuine residential IP, and that is checkable from any home connection in about thirty seconds.
Conclusion
Datacenter and residential proxies differ in exactly one respect, the ASN their addresses belong to, and that difference matters only to the extent that your target checks the ASN. On 2026-09-01 two protected sites refused a real residential IP outright, because they were reading the TLS handshake, the header profile and the absence of JavaScript rather than the address.
So the order of operations is the opposite of what this comparison usually implies. Determine what is refusing you before you buy a way around it. If it is a challenge page, you have a fingerprint problem and a browser fixes it. If it is a 429, you have a rate problem and rotation fixes it. If your data is location-sensitive, you have a geography problem, and that is the case where paying for controlled exits is genuinely the right answer.
Free next step: curl your target with a real user-agent string and look at both the status and the body size. A 403 with a two-kilobyte body from your home connection tells you the IP was never the problem, and it costs nothing to find out. Start at monid.ai.
FAQ
Where do mobile proxies fit in?
They are a third tier: IPs from cellular carriers, and they are the hardest to filter because carrier-grade NAT means thousands of real subscribers share one address, so blocking it blocks real customers. They are also the most expensive and the slowest. They earn their price on mobile-first platforms whose apps only ever see carrier traffic, and they are overkill almost everywhere else. The same caveat applies as to residential: a mobile IP does not fix a fingerprint.
Is static or rotating residential better?
It depends on whether your target tracks sessions. Rotating gives a new address per request, which spreads rate limits but looks bizarre if a site expects one user to stay on one connection through a multi-step flow. Static residential holds one address for a session, which is what you want for anything resembling a login or a paginated journey. The mistake is rotating mid-session and then wondering why a site logged you out, which reads as account takeover from the site's side.
Are residential proxy pools legal to use?
Using them is generally lawful; how the pool was assembled is the part worth asking about. Reputable providers pay households or compensate SDK users with disclosed consent. Some pools were built by bundling a proxy client into free software whose users did not meaningfully agree, and your traffic then exits through someone's home connection without their knowledge. That is a supplier diligence question rather than a technical one, and it is worth asking the provider directly how consent was obtained.
How do you compare per-gigabyte proxy pricing to per-page pricing?
Measure your pages. Take twenty representative URLs, record the transfer size, and take the mean. Multiply by your monthly page count to get gigabytes, and price that against a per-page fetch for the same volume. Two things usually surprise people: modern pages are heavier than expected, often one to three megabytes rendered, and proxy bandwidth is consumed by assets you do not want, since images and fonts bill the same as HTML. A per-page price includes rendering and maintenance that per-gigabyte pricing does not, which is the part the comparison usually leaves out. The real cost breakdown works through this arithmetic on a specific target.
Last updated September 2026.
