The four biggest anti-bot vendors — Cloudflare, DataDome, HUMAN (ex-PerimeterX), and Kasada — all fingerprint proxies at multiple layers before a request ever hits your target site. Here's exactly what they check, why cheap 'mobile' proxies fail, and how real-SIM 4G/5G IPs actually pass.
Most guides say "use mobile proxies and you'll be fine." That was true in 2020. In 2026 it's a half-truth that costs people accounts, scraping projects, and ad-verification contracts every day.
Modern anti-bot vendors — Cloudflare Bot Management, DataDome, HUMAN (formerly PerimeterX), and Kasada — don't just look at your IP address. They fingerprint you at five different layers before your first byte of HTML is ever rendered. If your "mobile proxy" is actually a datacenter IP wearing a mobile ASN sticker, or if your browser stack contradicts the IP type, you're already flagged.
This is a working engineer's guide to what these vendors actually check, why most cheap mobile-proxy providers fail those checks, and what a real mobile proxy stack has to look like to survive.
> Disclosure: we build xProxy — real-SIM 4G/5G mobile proxies. This article is deliberately vendor-neutral about detection tech; the technical descriptions below apply to any provider, ours included. If your existing proxies keep getting flagged, the checks below will tell you why.
Every request through Cloudflare / DataDome / HUMAN / Kasada passes through roughly the same pipeline. Understanding the order matters because you can be killed at layer 1 before layer 5 ever sees your beautiful anti-detect browser profile.
| Layer | What's inspected | When | Blocks at | |---|---|---|---| | 1 | IP / ASN / network reputation | TCP SYN | Edge, before TLS | | 2 | TLS handshake (JA3 / JA4 / JA4+) | TLS ClientHello | Edge | | 3 | HTTP/2 & HTTP/3 metadata | First HTTP frame | Edge | | 4 | Client-side JS challenge | On page load | Origin proxy | | 5 | Behavioral / ML session model | Over N requests | Session heuristic |
Cheap "mobile" proxies fail layer 1 or 2. Good mobile proxies + normal browser fail layer 4 or 5. Only a real mobile IP + a coherent browser + realistic behavior clears all five.
Let's take each layer in detail.
Every incoming connection is scored on network-level signals before a single byte of TLS is exchanged. This is done at the CDN edge — Cloudflare's 300+ POPs, DataDome's own edge, Akamai/HUMAN's edge — and it's the cheapest layer for the vendor to run, so it's the strictest.
Every IP belongs to an Autonomous System Number (ASN) with a registered type:
Vendors buy this classification from IPinfo, MaxMind, IP2Location, Spur, and their own crawlers. Every mobile-proxy claim is verified against this.
If you're using a "mobile proxy" that resolves to AS14061 DigitalOcean or AS16509 Amazon, you're not on a mobile ASN — you're on a datacenter ASN that some reseller labelled "mobile" in their dashboard. Cloudflare and DataDome catch this in microseconds.
What passes: IPs announced by an actual mobile carrier ASN (AS21928 T-Mobile US, AS22394 Verizon Wireless, AS20057 AT&T Mobility, AS12576 EE UK, AS15897 Vodafone DE, etc.). If the IP is BGP-announced by a carrier, the ASN check clears.
Beyond ASN, each IP has a rolling reputation score built from:
Real mobile carrier IPs (allocated via CGNAT) get rotated across thousands of real end-users every few hours, so their reputation naturally stays clean. The IP that was on your competitor's phone two hours ago is now on yours, and the carrier already burned any bad reputation off through natural churn.
Fake mobile IPs (i.e. datacenter IPs relabelled) never get that cleansing. They accumulate reputation debt fast.
Vendors track how many distinct browser fingerprints they see per IP per hour. A real mobile CGNAT IP sees dozens to hundreds of unique users — that's normal. A "residential" or "mobile" proxy from a reseller sees hundreds of very bot-like fingerprints per hour (all scraping the same site, all with HeadlessChrome, all missing a mouse). That ratio is the tell.
Cellular carriers in 2026 are heavily IPv6 (especially T-Mobile US which is IPv6-first with 464XLAT for legacy IPv4). If your "mobile" IP is a static IPv4 with no IPv6 counterpart, it's suspicious. Real mobile clients almost always announce both.