Datacenter IP detection: how it works and what it cannot tell you

Datacenter IP detection answers one question: does an address belong to a hosting or cloud company rather than to a home or mobile connection? Maskbreak calls such an address a cloud-server address. A match names the company whose network the address belongs to, not who is using it: a signup from a cloud address can be a script, a VPN user or an employee behind a company gateway. The outside facts below were checked on 30 September 2026.

Three ways to tell whether an address is a cloud server

1. The provider’s own range file. The large clouds publish the address blocks they operate as machine-readable files. A match is authoritative for one fact: the provider counts the address as its own. It says nothing about who rented it, or why.

Two cautions come with the files. Each covers only the provider that publishes it, and only what that provider chooses to list. And the right file matters: Google keeps Google Cloud’s customer ranges in cloud.json, keeps “the general list of Google IP addresses” in goog.json, and publishes separate files for its crawlers (Google Search Central). A check built on goog.json would flag Google itself.

2. The network that announces it. A public address is announced to the internet by an autonomous system, which RFC 1930 defines as a connected group of IP prefixes run by one or more network operators under a single, clearly defined routing policy. A routing-table dump maps each announced address to its AS number and the name its operator registered, so it also covers hosting companies that publish no file. But the name is a label, not a classification: AMAZON-02 says who routes an address, not what it is used for. Maskbreak shows the AS on a bare lookup for display only and never scores it.

3. Network intelligence on a live visit. On a real visit, measured by the browser SDK on your page, Maskbreak’s network intelligence classifies the connection and sets the cloud-server flag itself. The published ranges of nine providers, the four above plus DigitalOcean, Linode/Akamai, Vultr, Cloudflare and Fastly, are refreshed daily and can add the flag, never remove it; the hosting and cloud ranges page lists them.

A cloud-server address is context, not a verdict

Scripts run on cloud servers because servers are cheap to rent. Plenty of people and services you want to keep reach you from them too.

VPN exits. A VPN exit is a server too. Mullvad’s public server list names a hosting provider for each server (DataPacket, Tzulo and M247 were the most common on 30 September 2026) and marks 433 of its 553 WireGuard servers as rented. None of Mullvad’s hosting providers is among the nine whose range files Maskbreak reads (no server address fell inside those files that day), so for its exits the cloud-server flag rests on Maskbreak’s network intelligence alone. When it fires on a VPN exit, Maskbreak lists both reasons, vpn_detected and datacenter_asn, and a VPN alone is review under the base policy, not a block.

Search engine crawlers. Google asks site owners to verify its crawlers by reverse DNS or against the IP lists it publishes. Those lists overlap cloud space: on 30 September 2026, 23 of the 170 IPv4 blocks in its common-crawlers file (Googlebot and similar) sat inside ranges that cloud.json lists as customer-usable Google Cloud space. A range check built on cloud.json, Maskbreak’s included, reads those crawler addresses as cloud servers.

Build and test systems. GitHub says its Windows and Ubuntu hosted runners “are hosted in Azure and subsequently have the same IP address ranges as the Azure datacenters”, and does not recommend using those addresses as allowlists for internal resources (GitHub Docs). A test suite on those runners that signs up to your staging site arrives from Azure.

Company gateways. Companies that route staff browsing through a cloud security gateway send it out from the gateway’s addresses. Cloudflare’s documentation says that by default “traffic that exits through Cloudflare Gateway shares a source IP address with all other Cloudflare One Client users” (Cloudflare Docs).

Block on the cloud-server flag alone and you turn them away along with the scripts. The flag is worth reading next to the device check, not instead of it.

What a range list cannot see

Range lists also miss in the other direction. A residential or mobile proxy leaves through someone’s home line or a phone’s SIM card: no cloud file lists the address, and an ordinary ISP or carrier announces it, so neither the range files nor the network name points to a cloud. What can catch these visits is the live visit’s network reading, which returns proxy_detected and a block for an exit already tied to a known proxy pool, naming the pool when known, and the device check, which judges the browser itself and can flag an automated or fake browser whatever the address, though not always: the fake-browser flag stayed false for a default Aurorium profile on 30 September (the Aurorium test).

An exit nobody has tied to a pool yet reads network.residential: true, which means only that neither the cloud-server flag nor the proxy flag fired, not that the visit is clean. Residential vs datacenter proxies compares the two kinds of proxy, and how to detect residential proxies covers the tells that survive rotation.

How Maskbreak scores a cloud-server address

Maskbreak answers on two surfaces with different evidence, so one address can get two different answers.

On a live visit: allow on its own

POST /v1/evaluate, called from your server with the token the browser SDK collects, returns the flag as network.datacenter: true and the reason datacenter_asn. On its own the flag does not make the visit a threat: the decision is allow and the risk score is capped at 15.

Computed with Maskbreak’s response builder for a documentation-range address; legacy fields, evaluated_in_ms, the evidence fields and the device result are omitted. service, a provider name when known, is null here, and residential is false because the cloud-server flag fired. The public sandbox answers the test token test_datacenter with the same decision, score and reason, no account needed; its fixture also names the provider, "service": "AWS".

Next to a VPN, a proxy, Tor or a device threat (an automated or fake browser, an emulator, a virtual machine), the 15-point cap lifts, the flag’s 30 points count toward the score and the other signal sets the decision. Softer device flags such as private_browsing leave the visit at allow and 15; a disposable email address moves an allow to review:

The email row sends the optional email field, which is checked against a disposable-domain list and not stored. Device rows are computed with that one flag; a real device event can carry more flags or a tampering score that add points. One check stays quiet on purpose: when you send the visitor’s time zone, Maskbreak does not raise timezone_mismatch against a cloud-server address, because such an exit is expected to disagree with the device clock (timezone.checked reads false).

On a bare IP lookup: review at 40

GET /v1/lookup/{ip} and an address you type into the free IP lookup have only the address; the page’s check of your own connection, pictured above, is a live visit. In production a bare lookup checks the Tor exit list and published cloud ranges, nothing else, so a cloud-range hit is the whole of the evidence and reads review at 40: look closer, not block. The range check covers only the nine providers named above: a server at any other hosting company, such as a Mullvad server, reads known: false and allow unless it is a Tor exit. This address sits in a block AWS lists for EC2 in eu-central-1:

curl -s https://maskbreak.com/v1/lookup/18.192.1.10 \
  -H "Authorization: Bearer $MASKBREAK_API_KEY"

Computed with Maskbreak’s lookup code against AWS’s file and the routing table as of 30 September 2026. known: true means a list matched. country stays null because a bare lookup places nobody, and registration_country is where AS16509 is registered, not where the server or a visitor is. dch and proxied are legacy spellings kept for existing parsers. VPN and proxy verdicts, with the service named when known, need a live visit; proxy detection API vs IP lookup covers when each fits.

Changing the default

If no part of your product expects cloud-server visitors, the Rules tab’s Datacenter server rule can raise them to review account-wide (rules apply per account, not per endpoint); the answer then keeps engine_decision: "allow" and adds rule_matched: ["datacenter"]. A rule speaks only for the signal it names, so it never lowers a block that a proxy or an automated browser caused. To hold them at signup only, branch on datacenter_asn in your own code, as the sample below does.

A policy per surface

Decide per endpoint, not per provider:

• Signup, login and checkout. Read datacenter_asn together with the device check. A cloud-server address with a real browser behind it may be a VPN user or an employee on a company gateway; a request with no browser evidence may be a script that skipped the browser. Hold the second for a step you can verify.
• Free credit and trials. Where a new account earns something, a cloud-server address alone is a fair reason to ask for that step too.
• Your API. Expect cloud addresses there, because server-to-server calls come from them. Authenticate and rate-limit by key.
• Crawlers and exceptions. Verify crawlers against their operators’ lists, and pin exceptions to one visitor or one address, never to a provider’s ranges.

The server side of a signup check, with the browser SDK’s monocle and sentinel_fp fields on your form (the integration guide has the full watch-then-enforce version):

// Enforce path. Start in watch mode (log v.decision and v.reasons,
// always call next()) for a few days, then switch.
app.post('/signup', async (req, res, next) => {
  try {
    const r = await fetch('https://maskbreak.com/v1/evaluate', {
      method: 'POST',
      signal: AbortSignal.timeout(3000),
      headers: {
        'Authorization': 'Bearer ' + process.env.MASKBREAK_API_KEY,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        token: req.body.monocle,                  // the live visit, not a bare IP
        fingerprintEventId: req.body.sentinel_fp, // the device check
        email: req.body.email                     // checked, not stored
      })
    });
    if (!r.ok) throw new Error('Visitor check unavailable');
    const v = await r.json();
    if (v.test || v.sandbox || v.sample) throw new Error('No production verdict');
    if (v.decision === 'block') {
      return res.status(403).json({ error: 'Signup unavailable.' });
    }
    const onCloud = v.reasons.includes('datacenter_asn');
    // grantsTrialCredit: your own rule for signups that earn something
    if (v.decision === 'review' || v.degraded || !v.device ||
        (onCloud && grantsTrialCredit(req))) {
      return res.status(409).json({ next: 'verify_email' }); // a step you can verify
    }
    return next();
  } catch {
    return res.status(503).json({ error: 'Please try again shortly.' });
  }
}, existingSignupHandler); // your signup handler runs after the gate

Maskbreak’s Free plan includes 10,000 visitor checks a month with no credit card required, and authenticated IP lookups have their own allowance of ten times the plan’s checks; paid plans start at €29 a month (pricing). To check one address now, use the free IP lookup; VPN detection and proxy detection describe what a live visit adds.