Datacenter & cloud IP ranges,
refreshed daily.
Maskbreak ingests the published IP ranges of 9 major hosting and CDN providers daily — 87,137 prefixes as of 4 September 2026 — and folds them into every verdict as the cloud-server flag (datacenter_asn in a visitor check’s reasons, dch in the legacy signals).
How Maskbreak uses these ranges
The numbers below come from each provider's own published range feed — the same feeds the verdict pipeline refreshes daily, so a new range is scored within a day of publication rather than whenever a static database ships.
Range data adds a signal; it never overrides deeper network detection. Many VPN exits live in datacenters, so a range hit does not short-circuit tunnel analysis — an address inside a provider's ranges that is also a VPN exit gets both reasons, vpn_detected and datacenter_asn, and the VPN is what sets the answer to review.
Should you block datacenter traffic?
Not by default. A cloud-server address on its own is not a threat, so a visitor check answers decision: "allow" with a low risk score and still lists datacenter_asn in reasons (with network.datacenter: true). What the address means depends on the surface, and answering it per surface rather than per provider is the whole point. On a signup, login or checkout it is worth a second look: people usually browse from home and mobile networks, while scripts tend to run on rented servers. The same address calling your API is usually a legitimate backend. Check for the reason in each handler and apply that asymmetric policy there instead of a blanket block.
A Rules-tab rule on the Datacenter server signal (say, Review) applies to every visitor check on your account. It can raise a cloud-server-only visit to review or block; it never lowers a block that another signal, such as a proxy or a bot, caused.
curl -X POST https://maskbreak.com/v1/evaluate \ -H "Authorization: Bearer sk_test_sandbox" \ -H "Content-Type: application/json" \ -d '{"token":"test_datacenter"}'
The public sandbox key answers decision: "allow", risk_score: 15 and reasons: ["datacenter_asn"] with network.datacenter: true, the same shape a live check returns — no signup required. Details in the API docs.
Provider by provider
Ordered by IPv4 footprint. Counts are a 4 September 2026 snapshot; production refreshes daily.
AWS
Amazon Web Services is the largest public cloud. Its published IP ranges cover EC2, Lambda, and every other compute surface an attacker can rent by the minute.
Cheap, instantly provisioned compute makes AWS a common launchpad for scrapers, credential-stuffing runners, and headless-browser farms — while also carrying enormous volumes of legitimate server-to-server traffic.
Microsoft Azure
Microsoft Azure publishes the most granular range set of the providers here — tens of thousands of per-service prefixes.
Azure VMs and Functions appear in bot traffic for the same reason AWS does: pay-as-you-go compute with a clean corporate ASN. Legitimate enterprise integrations also live here in volume.
Google Cloud
Google Cloud Platform publishes its customer-usable ranges separately from Google’s own crawler infrastructure — this page tracks the customer ranges.
Google Cloud’s free-trial credits make short-lived scraping and abuse experiments cheap to run; its ranges also host plenty of legitimate APIs.
Oracle Cloud
Oracle Cloud Infrastructure (OCI) offers an Always Free tier that includes small compute instances.
Free compute that never expires is as useful to a hobby bot or a low-budget abuse script as to a side project, so an OCI address on a signup is worth reading together with the browser check.
DigitalOcean
DigitalOcean Droplets are low-cost virtual servers that anyone can start from a web console or an API in moments.
Low-cost developer clouds are a common place to run scrapers and account-farming scripts: a fresh Droplet with a real browser on top is a standard setup for scraping and multi-accounting. The server address alone cannot tell that script from a developer testing their own app, which is why the browser check matters here.
Cloudflare
Cloudflare publishes its own IP ranges (cloudflare.com/ips), with no separate list of WARP exit addresses, so this list does not identify WARP users. Most traffic you see through Cloudflare carries the visitor’s real IP in headers — these ranges matter when a request originates from Cloudflare infrastructure itself.
A visit that originates from Cloudflare’s own addresses (rather than being proxied through it for a website) usually comes from a Worker or other automation running on Cloudflare.
Cloudflare is a CDN, so the useful distinction is traffic originating from these ranges rather than traffic merely served through them — the cloud-server flag (datacenter_asn) applies to the former.
Linode/Akamai
Linode (owned by Akamai since 2022) is one of the oldest VPS providers, with a large, well-published range set.
Like every low-cost VPS host, Linode ranges appear regularly in automation traffic; a cloud-server address here on a checkout or signup is worth a second look.
Vultr
Vultr sells hourly VPS instances in dozens of regions, often used for lightweight proxies and automation runners.
Small, cheap, many-region VPS hosts are where one-off proxy exits and bot runners often get spun up — and torn down before blocklists catch up.
Fastly
Fastly publishes its CDN edge ranges. Like Cloudflare, requests originating from these ranges — rather than being served through them — are the signal of interest.
Fastly Compute (formerly Compute@Edge) and similar products mean code, not people, initiates connections from these ranges.
Fastly is a CDN, so the useful distinction is traffic originating from these ranges rather than traffic merely served through them — the cloud-server flag (datacenter_asn) applies to the former.
Free plan: 10,000 visitor checks a month, no card. Paid plans from €29 a month.