What a Residential Proxy Actually Is — and When You Don't Need One
Residential IPs cost 10-30x datacenter IPs, and plenty of workloads need none at all. Here is the mechanism, and how to tell which case you are in.
11 min read · 20 Aug 2026
You wrote a scraper. It worked on your laptop. You deployed it and it stopped working immediately — not gradually, not after a thousand requests, but on the first one from the server.
Every result you find says the same thing: you need residential proxies. So you go pricing them, discover they cost between $0.27 and $4.20 per gigabyte depending on who you ask, and start doing arithmetic about a line item you did not have yesterday.
Some of you need them. A meaningful number of you do not, and are about to pay for a solution to a problem you could have designed around. This post is about telling the two cases apart, which requires understanding the mechanism rather than the marketing — and the mechanism is much simpler and much dumber than most explanations suggest. If you have already concluded you need them and want the number that decides the budget, that is cost per successful request.
The four kinds of IP, and where they come from
"Proxy" is a routing concept. The thing that determines whether a platform blocks you is not the routing, it is where the IP address lives in the internet's ownership records. Four categories matter.
Datacenter. An IP owned by a hosting provider — AWS, Hetzner, DigitalOcean, OVH. Your server has one right now. They are abundant, they cost approximately nothing, and they are trivially identifiable, for reasons we will get to in a moment.
ISP / static residential. An IP allocated to a consumer internet provider but hosted in a datacenter, with the ISP's cooperation. It looks residential in the ownership records while behaving like a server IP — always on, high bandwidth, and yours alone. Typically $0.30 to $3 per IP per month rather than per gigabyte.
Residential (rotating). An IP belonging to an actual home internet connection. This is the expensive one, sold per gigabyte, and it is worth understanding where the supply comes from: these are real people's connections, enrolled either through a paid opt-in program or — more commonly — through an SDK bundled into a free app or browser extension, where the user agreed to something in a terms-of-service screen they did not read. The quality of that consent varies a great deal between providers, and it is a reasonable thing to ask a vendor about before you buy. Some publish their sourcing. Not all do.
Mobile. An IP from a cellular carrier's pool. The most expensive category and the most trusted by platforms, because carrier-grade NAT means a single mobile IP may be shared by thousands of genuine users at once. Blocking one is expensive for the platform, so they are reluctant to.
The price ladder tracks scarcity, and scarcity tracks how hard the IP is to acquire in bulk. Nothing more mysterious than that.
The mechanism: it is an ASN lookup
Here is the part that reframes the whole problem. People imagine that being detected as a bot involves machine learning on their behaviour, or TLS fingerprinting, or mouse-movement analysis. Those things exist, and they are not what blocked your first request.
Every IP address on the internet is announced by an autonomous system, identified by an ASN. That mapping is public, by design — it is how routing works. The regional registries publish who owns which blocks, and the major cloud providers go further and publish their entire allocated ranges as downloadable files so their own customers can configure firewalls.
So the detection is not a model. It is a join.
IP → ASN → owner → is this owner a hosting provider?
Amazon's ranges are a published JSON document. So are Google Cloud's and Azure's. Hetzner, OVH, DigitalOcean, Linode — all enumerable from public BGP data, all maintained as commercial IP-intelligence feeds you can buy off the shelf. A platform does not need to observe your behaviour at all to know that the request came from a machine in a rack. It knows before your first byte of application data arrives.
This has one very important consequence: perfecting your client does not help. You can match a real browser's TLS fingerprint exactly, replay a plausible header order, run a full headless browser with realistic timing, and still be blocked on request one from a datacenter IP — because none of that is being examined. The decision was made from the source address.
That is why the failure is so abrupt and so total. It is not a rate limit you are tripping. It is a category you are in.
Which cuts both ways, and here is the useful half: if a platform does not do this lookup, or does not act on it, none of it applies to you and residential IPs buy you nothing at all.
Where you do not need one
Plenty of the public web is genuinely happy to serve a datacenter IP. Some of it because the operator does not care, some because the endpoint was explicitly built for third-party consumption. From what we run in production, verified against live traffic on 2026-08-20:
YouTube — the entire surface we use. Channel metadata, video metadata, channel video listings, search, and full transcripts all work from a plain datacenter IP with no proxy of any kind. That includes the expensive part: minting the BotGuard proof-of-origin token needed for gated caption tracks happens over an ordinary connection from an ordinary server. YouTube is the most open large surface on the web and it is not close.
Official APIs behind a token. If a platform gives you a documented API and an access token, the token is your identity and the IP is irrelevant. Meta's Ad Library runs on the official Graph API — public data, published under regulatory mandate — and needs a token but no proxies. You are an authenticated client, not an anonymous one.
Endpoints designed for embedding. oEmbed and syndication endpoints exist so that third-party servers can render content. Blocking datacenter IPs there would break the feature. A single public tweet is retrievable through the syndication path from an unproxied datacenter IP, verified on the same date.
RSS. Still there, still unauthenticated, still uninterested in where you are calling from. YouTube publishes a channel feed per channel ID. If fifteen recent uploads is enough, that is the entire integration.
Anything you can cache. This is the one people skip and it is often the largest win available. If a hundred customers ask for the same creator profile within an hour, that is one upstream request and ninety-nine cache hits. Cache-hit rate is a multiplier on every other cost in your system, including the proxy bill — and unlike the proxy bill, you control it.
There is a real architectural point buried in that list. Marginal cost per request in this category varies by roughly two orders of magnitude between platforms, almost entirely because of this one question, and flat per-request pricing quietly makes YouTube users subsidise Instagram users.
Where you do need one
Instagram, and Twitter's profile and timeline endpoints, rate-limit requests from datacenter IPs — that matches the published experience of everyone else working on these platforms, and it matches what we see: those endpoints in our own product are marked as needing a residential proxy and do not run without one configured.
What we are not going to give you is a table of measured success rates by platform and IP type. We have not run that test properly — our Instagram endpoints are gated at preflight for want of residential IPs, and our only live probes hit rate limits within two attempts, which is a sample of two, not a measurement. Publishing percentages derived from that would be inventing data, and it is the exact thing that makes every other article on this topic worthless. When we have run it, we will publish it, including the parts that make us look bad.
What we can say without measuring anything: if your target is a logged-out social platform other than YouTube, assume you need residential IPs and budget for them. The economics of these platforms make aggressive datacenter blocking obviously correct for them, and there is no clever header that changes an ASN.
What it costs, honestly
Residential bandwidth ranges from about $0.27/GB at the aggressive end to $4.20/GB at the enterprise end. Those are vendor-published figures gathered on 2026-08-20 and they are not equally trustworthy — some come from live pricing pages, some from secondary sources.
Bandwidth pricing is also not directly comparable to anything, so convert it. At roughly 150 KB per request — a reasonable figure for an Instagram profile fetch — one gigabyte is about 6,700 requests:
| $/GB | $/1,000 requests |
|---|---|
| $0.27 | $0.04 |
| $1.00 | $0.15 |
| $1.50 | $0.22 |
| $3.00 | $0.45 |
| $4.20 | $0.63 |
Three caveats, all of which matter more than the numbers.
Those figures assume a working scraper. They are bandwidth costs, not success costs. A residential IP gets your request accepted; it does not parse the response, handle the captcha, manage the session, or fix things the week the platform changes its defences. That engineering time is the real expense for most teams and it does not appear in any table.
Divide by your success rate. Bandwidth spent on a blocked request is bandwidth spent. If eight requests in ten succeed, your true cost per useful response is 25% higher than the table says. This is the term everyone omits and it is usually the largest correction.
Per-gigabyte and per-credit pricing are not comparable without arithmetic. Scraper APIs that bill in credits typically charge a 10x multiplier for residential requests, which means a plan advertising a million credits delivers a hundred thousand residential requests. That conversion is worth doing before you buy, not after.
The decision, as a checklist
Work down this list. Stop at the first "yes."
- Is there an official API with a token? Use it. The IP question disappears, and you get a documented contract and a support channel along with it. Check for a regulator-mandated one — ad transparency archives exist because legislation required them, and they are the least contested data in this category.
- Is there an RSS, oEmbed, or syndication endpoint that covers your need? These are built for third-party servers. They will serve your datacenter IP happily and they will not break next month.
- Does the target actually block datacenter IPs? Test it before you assume. Deploy the simplest possible fetch to a cloud box and run it a few hundred times over a few hours. This costs an afternoon and it is the only step here that produces evidence about your target rather than someone else's blog post. Watch for a 200 with an empty body as well as an outright error — plenty of platforms block quietly, and a naive test will report success while returning nothing.
- Can caching or change detection cut your volume by an order of magnitude? If you are re-fetching the same thousand profiles hourly and 97% of them are unchanged, the proxy bill is not your problem — the polling pattern is.
- Still blocked, still need it? Now buy residential, start with pay-as-you-go, and do not commit to an annual plan until you have measured your own success rate against your own targets for a week.
Most of the value is in steps 1 through 4, and most people start at step 5 because that is where the search results point them. The search results point there because nearly every article about proxies is published by a company that sells proxies.
We do not sell them, and we still buy them — YouTube and the Meta Ad Library run through no proxy at all, and Instagram and Twitter run through a multi-provider residential pool with failover. That split is not a clever optimisation. It is just what happens when you ask the question per platform instead of once, at the start, for all of them.
Sources and dates. Vendor pricing, per-request conversions, and live endpoint probes are recorded in research/11-proxy-and-scraper-providers.md, gathered 2026-08-20, with a verification column noting which figures came from live probes and which from vendor pages. Two vendors' documented API hostnames did not respond to us at all — the details are in the buyer-side proxy comparison. Pricing pages in this category change frequently; archive anything you plan to rely on.