A Proxy Detection API Built for Residential Proxies, Not Just Datacenter Ranges
Maskbreak checks each live visit to your signup, login or checkout and tells you whether it arrives through a proxy, whether the exit sits in a hosting range or on a consumer ISP, and, when the operator is known, which service it is (for example BRIGHT_DATA). Datacenter proxies are the easy half; the traffic that hurts exits through real homes on real ISPs, rented by the gigabyte. A proxy exit returns decision: "block" by default, and the device signals still see the same browser when the exit IP rotates. Free plan: 10,000 visitor checks a month, no card.
Why proxy traffic gets past IP filtering
Residential exits look exactly like customers
A residential proxy routes the request through a real consumer device on Comcast, Vodafone, or Deutsche Telekom. The address has normal ISP history, a normal ASN, and a plausible geolocation — every naive check reads it as a legitimate home user.
ASN lists only catch the lazy half
Blocking hosting-provider ASNs stops datacenter proxies and nothing else. The residential pool's entire value proposition is that its exits sit inside the same consumer ASNs as your paying users — block the ASN and you block your customers with it.
Rotation defeats per-IP controls
Commercial pools advertise tens of millions of rotating addresses. An attacker can present a fresh residential IP on every single request, so rate limits, velocity rules, and IP-based bans never accumulate enough history to fire.
Geolocation becomes attacker-controlled
Residential pools sell city-level exit targeting. Geo-fencing, regional pricing, and "impossible travel" logic all assume the IP's location means something — behind a proxy pool, it means whatever the attacker selected from a dropdown.
What Maskbreak does for you
- Separate signals for proxy, VPN, Tor, and datacenter origin — residential proxies don't hide in an "anonymous" catch-all
- Named attribution when known:
network.servicereturns the operator behind the exit, e.g.BRIGHT_DATA network.datacenterseparates hosting ranges from consumer ISP space;network.residentialis true whenever neither datacenter nor proxy fired, so a VPN or Tor exit can read residential too; it is not a clearance- Device signals tie rotating IPs back to one machine — headless browsers, antidetect tooling, and repeat hardware all surface
- Signals and score returned together, so blocking policy stays in your code
One call, both layers
For browser traffic, /v1/evaluate scores the network and the device in one round trip — the proxy verdict plus the fingerprint evidence that survives IP rotation. Screening bare IPs server-side (logs, webhooks, batch jobs)? Use GET /v1/lookup for Tor-exit and datacenter/cloud checks — proxy and VPN verdicts need the live session, so keep /v1/evaluate on the request path. For the signup-flow trade-offs, read Proxy detection API vs IP lookup; to weigh other providers, read our proxy detection API comparison. The example starts in watch mode: it logs each verdict, lets every request through and fails open if Maskbreak is unreachable. After a few days, compare the log with the Events in your dashboard, then uncomment the enforce line; the integration guide has the full enforce checks.
// Full evaluation: network + device layers in one verdict // Watch mode first: log the verdict, always continue, fail open const body = req.body || {}; // sentinel.js adds monocle + sentinel_fp to your form let risk = null; try { const verdictRes = await fetch('https://maskbreak.com/v1/evaluate', { method: 'POST', signal: AbortSignal.timeout(5000), headers: { 'Authorization': 'Bearer ' + process.env.MASKBREAK_API_KEY, 'Content-Type': 'application/json' }, body: JSON.stringify({ token: body.token || body.monocle, // network evidence fingerprintEventId: body.fingerprintEventId || body.sentinel_fp, // device evidence tz: body.tz || body.sentinel_tz }) }); if (verdictRes.ok) risk = await verdictRes.json(); } catch {} // unreachable or timed out: your handler still runs // risk.network.proxy -> true when the request exits a proxy // risk.network.datacenter -> exit sits in hosting space (false for a residential exit) // risk.network.service -> named operator when known: 'BRIGHT_DATA' console.log('[maskbreak]', JSON.stringify({ decision: risk?.decision ?? null, reasons: risk?.reasons ?? null, risk_score: risk?.risk_score ?? null, degraded: risk ? !!risk.degraded : null, network: risk?.network ?? null })); // Enforce later: if (risk?.decision === 'block') return res.status(403).json({ error: 'Request rejected' });
What a proxy verdict looks like. This is an excerpt of the public sample response, which is built by the same function as a live /v1/evaluate call (the legacy fields are left out):
curl "https://maskbreak.com/v1/evaluate/sample?scenario=proxy"
{
"sample": true,
"decision": "block",
"risk_score": 80,
"network": {
"vpn": false,
"proxy": true,
"privacy_relay": false,
"datacenter": true,
"anonymous": true,
"tor": false,
"residential": false,
"service": "BRIGHT_DATA"
},
"reasons": ["proxy_detected", "datacenter_asn"],
"evaluated_in_ms": 28
}A proxy exit blocks by default; a VPN on its own is only flagged for review. In this sample the exit sits in hosting space, so datacenter is true as well. A residential exit returns proxy: true with datacenter: false, and residential stays false whenever a proxy is seen. service is null when the operator is not known.
Connect through the proxy you're worried about and run the live scanner on the homepage — it shows the verdict Maskbreak would hand your server. The free IP lookup tool checks a bare address for Tor exit and cloud-server origin only; proxy verdicts need a live visit. Both are keyless previews with a reduced signal set; the full API adds device intelligence and multi-account linking.
The signals that matter here
Residential exits, identified by intelligence — not inference. You cannot compute your way from an ASN to "this specific Comcast address is currently a rented proxy exit." That knowledge comes from curated, continuously refreshed tunnel intelligence — Maskbreak's primary network source — which tracks which addresses are actively carrying proxy traffic right now, as pools rotate. When the operator is attributable, network.service names it: BRIGHT_DATA is a very different conversation with your fraud team than "anonymous IP."
The datacenter layer, hardened by the providers themselves. For the easier half, Maskbreak combines tunnel intelligence with address ranges that cloud providers publish about their own infrastructure, so the dch signal stands on authoritative ground. The layering is strict by design: published ranges only ever add evidence — a range hit can never short-circuit tunnel detection, because VPN and proxy exits frequently live inside datacenters too.
The device behind the pool. Rotation changes the IP; it doesn't change the browser. When the client snippet runs, Maskbreak's device layer can flag automation, antidetect browsers with spoofed fingerprints, and virtual machines, and its device ID (visitor_id) with a times_seen counter ties request #50 to the same device as request #1, whichever exit carried it. Account links are per-customer and stored as hashes only.
Your policy, not ours. A proxy exit blocks by default, but it doesn't have to — plenty of corporate egress and privacy tooling proxies traffic legitimately. Apple’s iCloud Private Relay is the one the engine handles itself: a relay Maskbreak’s network intelligence recognises is reviewed, not blocked (reason privacy_relay; network.proxy stays true). Every response carries the individual signals, the named service, and the reasons array alongside the decision, so a rule can keep blocking proxied checkout attempts while sending proxy-flagged logins to review. For the deeper story on why this class of traffic breaks IP-only defenses, read the residential proxy detection guide.
Live visit or bare IP: what each check can see
A live visit is POST /v1/evaluate with the token the browser snippet creates. A bare IP is GET /v1/lookup/{ip}, or the free IP lookup tool.
| Signal | Live visit | Bare IP |
|---|---|---|
| Proxy exit (residential or datacenter) | Yes: block by default, service named when known | No: needs a live visit |
| VPN | Yes: flagged for review | No: needs a live visit |
| Tor exit | Yes | Yes, from the Tor Project's exit list |
| Cloud-server range | Yes | Yes, with the provider named |
| Automation, fake browser, VM | Yes, when the client snippet runs | No |
Common questions
/v1/evaluate response names it in network.service — for example BRIGHT_DATA for a Bright Data exit or PROTON_VPN for a VPN — and returns null when it isn't. That attribution turns a generic "proxy detected" into something you can write policy against and show an analyst.residential: true with the proxy signal false and adds nothing to the risk score. The proxy signal fires on addresses currently seen acting as proxy or tunnel exits, which can include a home line whose owner runs a bandwidth-sharing app. Every response carries the individual signals alongside the score, so you decide what happens on a hit: block, review, or extra verification.visitor_id and its times_seen counter tie request #50 back to the same device as request #1, and automation or antidetect tooling shows up in the device signals when that evidence is collected, whichever proxy carried the traffic.GET /v1/lookup/{ip} and the free IP lookup tool check a bare address for Tor exit and cloud-server origin. Proxy and VPN verdicts, and the service name, need a live visit: the browser snippet creates a token, your server sends it to /v1/evaluate, and the verdict comes back in one response.See the proxy, name the network when known, keep the customer
Free plan: 10,000 visitor checks a month, no card. Paid plans from €29 a month. Flags residential and datacenter proxy exits, fake browsers and automation on live visits.