Datacenter Proxies vs Residential: Which One Fixes Your Block

Get a page that blocks your requests without choosing a proxy type. Paste this into your agent:

Set up https://monid.ai/SKILL.md, and then use Monid to fetch https://www.zillow.com/homes/for_sale/ as Markdown and tell me which city the listings are for and how many results the page shows.

One prompt fetches a page that refuses a plain request. 1 min setup · 3-8 hrs saved.

Your requests keep coming back 403, and every guide tells you to buy one of two things: datacenter proxies, which are cheap, or residential proxies, which look like real households. This guide tests that advice on two protected sites on 2026-10-16 and shows what actually decided the outcome, then how to find your own answer in a few minutes. The fetches run through Monid, the OpenRouter for agent tools: one key, one balance, every tool priced per call.

Do you need to pick between datacenter and residential proxies, or is there an easier way?

Often you do not need to pick. Monid sells fetch endpoints, not proxies, so you ask for a page and the network and browser profile come with the call.

• Pay per call. The fetch endpoint used in this guide bills $0.002533 per successfully scraped page (Verified 2026-10-16 on the web extraction tools page). Failed or blocked requests are not billed. You buy calls as you need them, with no minimum top-up and no subscription.
• One install, every tool. The same key and balance call the fetch endpoints and every other tool on Monid, so a second data source is another call and not another vendor account.
• Lives inside your agent. Your agent reads SKILL.md, learns discover, inspect and run, and fetches pages on demand. Setup is about a minute.

The rest of this guide is the evidence, so that you can see for yourself which cases a proxy type decides and which it does not.

What is the difference between datacenter and residential proxies?

The difference is who the IP address is registered to. A datacenter proxy uses an address owned by a hosting company; a residential proxy uses an address that a consumer internet provider assigned to a household connection.

Datacenter proxies

These come from server farms. They are fast, cheap and sold in large blocks, and they are easy to recognise as servers, because the hosting company's network ranges are public. A site that wants to treat server traffic differently can do so by looking at the network the address belongs to.

Residential proxies

These exit through consumer lines, so the network name looks like an ordinary internet provider. They are slower, usually billed by the gigabyte, and harder for a site to separate from a visitor at home. The price you pay is mostly for that cover.

What a proxy does not change

A proxy changes the address a request comes from. It does not change the request. The TLS handshake, the order and casing of headers, whether JavaScript runs and whether a real browser is behind the request all stay yours. That gap is what the next section measures, and it is also why a mobile proxy is a third type with the same limit (see the FAQ).

The two types also differ in how they are sold. Datacenter pools are often priced per address or per port, residential pools per gigabyte, and a modern page can weigh a couple of megabytes. The arithmetic for your own pages is in the FAQ.

Does a residential proxy get past anti-bot blocks that a datacenter proxy cannot?

Not as a rule. On 2026-10-16 the clearest example was a datacenter fetch succeeding on a page where a plain request from an ISP line failed. We fetched the same two URLs three ways and recorded what came back.

The first way is curl with a current Chrome user agent from our own machine. ipinfo.io placed it in San Francisco on AT&T's network (AS7018). The second is a free fetch endpoint, tinyfish /fetch, whose exit address the rotating proxy guide measured on 2026-10-16 as an Amazon datacenter address. The third is context.dev /web/scrape/markdown, whose inspect page says JavaScript rendering, anti-bot bypass and premium residential proxies are handled server-side.

Read the table by column and by row. The datacenter fetch got into Zillow, which refused curl from the ISP line. The fetch described as residential did not get into G2 that day, and neither did the other two. If address type alone decided these outcomes, the columns would sort in the opposite order.

What the blocked responses said

The two 403s from curl were not generic errors. The G2 body was a 1,704-byte page titled g2.com that asked us to enable JavaScript, with a response header x-datadome: protected. The Zillow body was titled "Access to this page has been denied", carried a px-captcha marker, and came with x-px-blocked: 1. Both are challenge pages from a bot-detection layer, small enough that a size check catches them even when the status is not 403.

Why the address was not the deciding factor

A challenge layer scores the whole request: the handshake, the headers, whether script runs and how the client behaves, with the address as one input among several. curl fails the parts that a browser passes, from any address. tinyfish /fetch renders pages in a real browser, and it read Zillow. G2 refused all three, so on that site no proxy type or tool we tried helped, and it may take a different fetch service or a session you control.

Treat one day of results as one day of results. These sites change their rules, and a call that fails today can pass next week. The useful part is the method in the next section, which takes minutes and costs nothing for the first step.

📖 See also What gets through when a scraper is blocked

How do you find out which layer is blocking you?

Test the same URL at three layers and read the status and the body size of each. The first test is free, and it is the one that saves you from buying bandwidth you did not need.

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. A plain request from your own machine

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"

A 200 with the content you expected means you needed no proxy. A 403 with a body of a few kilobytes is a challenge page. A 429 is a rate limit, which is the one problem that spreading requests across addresses fixes.

Step 2. A free browser fetch

tinyfish /fetch takes a list of URLs in a POST body, so it uses -i and not --query:

monid run -p tinyfish -e /fetch -i '{"urls":["https://www.zillow.com/homes/for_sale/"],"ttl":0}'

It billed 0 on 2026-10-16. A page it cannot read comes back in errors[] with a code such as target_http_error, and the failure of one URL does not fail the batch. The endpoint's own notes say it has no anti-bot bypass.

Step 3. A fetch with the proxy and browser included

monid run -p context.dev -e /web/scrape/markdown --query '{"url": "https://www.zillow.com/homes/for_sale/", "country": "us", "maxAgeMs": 0}'

country is a two-letter code and maxAgeMs set to 0 forces a fresh fetch. The call returned a Markdown body, a title and page metadata, and billed one unit of $0.002533 (Verified 2026-10-16). When a page cannot be read, the run fails and nothing is billed: our G2 attempt returned WEBSITE_ACCESS_ERROR with credits_consumed at 0.

Step 4. Assert on the content so a silent block shows up

def usable(md: str) -> bool:
    if len(md) < 1500:        # challenge pages are small
        return False
    return "results" in md    # something only the real page has

On our Zillow runs the real page was 9,551 and 24,028 characters, and the empty result was 936. A length floor alone would have caught a challenge page, but it would also mark a legitimately empty result as a failure, so pair it with a word you expect.

Does the proxy location change what a page returns?

Yes, and for many jobs it matters more than the proxy type. The same Zillow URL, zillow.com/homes/for_sale/ with no location in it, returned a different place on every route we tried on 2026-10-16.

The city on each page is Zillow's own guess from the caller's address, not the proxy's location. An address-echo page fetched with the same country setting on 2026-10-16 came from Oldenburg, Germany for de and from Union City, New Jersey for us.

Every one of those responses was a success. Nothing in the status told us that the place was not the one we wanted.

Setting a country does not pin a city

The two us runs landed in two different states, so a country code selects where the exit is, not which city the site picks for you. The two de runs landed on the same Missouri town twice, and the page said there were no matching results there. A search page with no location in the URL is a guess made by the site, and the guess depends on the network it sees.

Why this is the quiet failure

A block is loud: a 403, an alert, a fix. A wrong-place result is quiet. It has the right shape, the right fields and a 200. If you aggregate many pages this way, the composition of your dataset is decided by wherever the exits happened to be.

What to do about it

Put the location in the URL or in a parameter, and treat any page you did not pin as being about an unknown place. Check the place in the response against the place you meant: on Zillow it sits in the page title and the first heading.

Controlled geography is a real reason to buy proxy access. Prices, search rankings, catalogues and ad delivery differ by market, and no amount of browser work answers what a shopper in Munich sees from an exit in Missouri.

📖 See also What a self-hosted proxy does not change

Which endpoint should I use for which job?

Prices come from monid inspect on 2026-10-16, and current figures are at monid.ai/tools. None of these rows is a proxy: each is a fetch that includes whatever network and browser the provider runs. Use tinyfish/fetch first because it is free and tells you whether a browser alone is enough, then context.dev for the pages it cannot read, and the HTML endpoint when you need your own selectors. The pages that neither reads, G2 in our test, are the case for the next section.

📖 See also Fetching in Python without writing a scraper

When is another route a better fit?

You need controlled geography. If the question is what a shopper in one particular city sees, you need an exit in that city and a way to pin it. A country code, as the Zillow test showed, does not do that.

You are rate limited, not blocked. A 429 is a counter per address, and spreading requests across a pool is the right fix. Datacenter addresses are enough for sites that do not filter by network, and residential ones for sites that do.

You already run your own browser stack. If you operate Playwright at scale and have solved the fingerprint, proxies are the missing piece, and buying them directly is simpler than routing through a fetch call.

The page is one nothing reads. G2 refused every route on 2026-10-16. That calls for a session you control, an official data channel, or a different source.

Volume makes bandwidth cheaper than pages. At large volumes per-gigabyte pricing can beat per-page pricing. Work the crossover out from your own page weights.

And the disclosure: we sell fetch endpoints, not proxies, so this guide leans toward fetching. The measurements stand on their own, and you can repeat the three steps above in about ten minutes.

Conclusion

Datacenter and residential proxies differ in one thing, the network their addresses belong to, and that matters only when the site you target decides on the network. On 2026-10-16 it did not decide the two sites we tried: a datacenter fetch read Zillow where curl from an ISP line was refused, and G2 refused all three routes.

Two things matter more than the choice. First, find the layer before you buy: run the plain request, then the free browser fetch, then the full fetch, and read the status and the size each time. Second, pin the location: the same Zillow URL returned four different places across five fetches, and every one of them was a clean 200.

How the time saved was estimated: comparing and trialling two proxy vendors, wiring a pool into a scraper and debugging challenge pages takes roughly 3 to 8 hours for a first working fetch, which is the range in the pitch. The 1 minute is the install, key and first call once you have a Monid key. Free next step: run monid inspect -p context.dev -e /web/scrape/markdown, then run Step 1 against your own target. Start at monid.ai.

FAQ

Published September 2026.