Why IP Blocklists Fail: Detecting Residential Proxy Traffic in 2026

I spent three months in late 2025 watching our datacenter IP blocklist become less effective week by week. Campaigns that had clean traffic suddenly showed the familiar patterns—high bounce rates, zero conversions, suspicious timing—but the IPs all traced back to Indonesian ISPs. Telkomsel. Indihome. XL Axiata. Real carriers, real residential addresses.

The fraud hadn't stopped. It had evolved.

The Shift to Residential Proxies

For years, bot operators ran traffic through datacenters. AWS, DigitalOcean, Hetzner—if you could identify the ASN, you could block it. Detection was straightforward: maintain a list of datacenter IP ranges, check incoming traffic against it, block matches.

That approach worked until residential proxy networks scaled up. These services route traffic through real consumer devices—phones with malware, compromised routers, "money-making" apps that sell users' bandwidth. The traffic exits through genuine home connections.

From a network perspective, this traffic looks legitimate. The IP belongs to a real ISP. The geolocation matches. The ASN is residential, not commercial. Every check that worked against datacenter traffic passes.

How Residential Proxy Networks Operate

The economics are simple. Proxy providers pay users—often in developing markets—small amounts to install apps that share their bandwidth. Some users know what they're signing up for. Many don't; the functionality is buried in "free VPN" apps, mobile games, or utility software.

The provider aggregates millions of these exit nodes into a pool. Customers—including bot operators—route requests through the pool. Each request exits through a different residential IP, often in the target geography.

For fraud targeting Indonesian campaigns, this means traffic that:

• Comes from Indonesian residential IPs
• Shows correct Indonesian timezone
• Reports Indonesian carrier names
• Passes basic geo-verification

Your IP blocklist sees a Telkomsel customer in Jakarta. In reality, it's a bot operator in Eastern Europe routing through that customer's phone.

Why Traditional Detection Fails

Let's be specific about what stops working:

1. IP Reputation Databases

Services like MaxMind, IP2Location, and IPinfo classify IPs by type: residential, commercial, datacenter, mobile. Residential proxies appear as residential because they are residential. The classification is technically correct—it's just not useful for fraud detection anymore.

Some databases now flag "proxy" or "VPN" status, but residential proxy networks specifically design their traffic to avoid these flags. The exit nodes are real consumer devices, not VPN servers.

2. ASN Blocklists

Blocking entire ASNs worked when fraud came from a handful of hosting providers. You can't block AS7713 (Telkomsel) or AS17974 (Indosat)—you'd eliminate your actual Indonesian audience.

3. Geographic Verification

If you target Indonesia and verify that traffic comes from Indonesian IPs, residential proxies pass easily. They exit through Indonesian IPs by design. The geo-check that protected you against Ukrainian datacenter traffic does nothing here.

4. Single-Signal Detection

Any detection method that relies on one signal—IP reputation, ASN, country, or even user agent—can be spoofed or routed around. Residential proxies specifically target IP-based detection because it was the dominant approach.

Signals That Still Work

Residential proxies solve the IP problem. They don't solve everything else. The traffic still has to execute in a browser (or pretend to), and that execution leaves traces.

Browser Fingerprint Consistency

A visitor claims to be on an iPhone in Jakarta. Their WebGL renderer reports an Intel GPU. Their screen resolution is 1920x1080. Their touch events don't fire.

Each of these signals alone might have an innocent explanation. Together, they indicate a desktop machine pretending to be mobile—common in bot setups that route through mobile residential IPs but execute on server hardware.

Key consistency checks:

• Device vs. GPU: iPhones always show Apple GPUs. Android devices show Qualcomm, Mali, or PowerVR. Intel/NVIDIA on mobile is a mismatch.
• Screen vs. UA: Mobile user agents with desktop resolutions indicate spoofing.
• Touch capability: Mobile browsers report touch support. If touch events never fire on a "mobile" visitor, something's wrong.
• Platform APIs: Different browsers expose different JavaScript APIs. Chrome on Android behaves differently from Chrome on Windows, even with identical user agent strings.

Behavioral Analysis

Bots interact with pages differently than humans. Even sophisticated bots that simulate mouse movements often fail on timing and variation.

What we look for:

• Mouse movement patterns: Humans move in curves with varying acceleration. Bots often move in straight lines or with suspiciously consistent speed.
• Scroll behavior: Real users scroll progressively, pause to read, sometimes scroll back up. Bots often execute instant scrolls or perfectly uniform scroll events.
• Click positioning: If more than 50% of clicks land exactly center-screen, that's not human behavior.
• Timing distribution: Human actions follow natural timing distributions. Bot actions often cluster at specific intervals or execute too quickly.

JavaScript Environment Integrity

Headless browsers and automation frameworks leave fingerprints in the JavaScript environment:

• Automation markers: Selenium sets navigator.webdriver. Puppeteer leaves __puppeteer_evaluation_script__. CDP-based tools expose Runtime.evaluate artifacts.
• Prototype tampering: Bots that override native functions to hide detection often leave inconsistencies in prototype chains.
• Missing features: Headless browsers historically lacked plugins, proper font rendering, or full WebGL support. Modern headless browsers have improved, but gaps remain.

Request Velocity

The same fingerprint hitting your endpoint 50 times in a minute isn't 50 different users on the same phone—it's one bot cycling through residential IPs. Track fingerprint-level velocity, not just IP-level.

Building Layered Detection

No single signal catches everything. The solution is layered detection that combines multiple weak signals into strong decisions.

The Scoring Approach

Rather than binary pass/fail checks, assign scores to suspicious signals:

• iPhone user agent + Intel GPU: +40 points
• Mobile UA + desktop resolution: +25 points
• No mouse movement on desktop: +25 points
• Straight-line mouse paths: +30 points
• Automation markers detected: instant fail
• Same fingerprint >10 requests/minute: instant fail

Set a threshold—say, 50 points—where accumulated soft signals trigger blocking. Hard signals (automation markers, extreme velocity) bypass scoring entirely.

Continuous Learning

Fraud patterns evolve. Your detection needs to evolve with them.

Track which signals correlate with non-converting traffic. If a new pattern emerges—a specific browser version, a particular fingerprint configuration—your system should flag it for investigation before it scales.

We maintain a self-learning blocklist that automatically escalates fingerprints showing fraud patterns. First offense gets scored. Repeated offenses get blocked. The system adapts without manual rule updates.

What This Looks Like in Practice

A request arrives from a Telkomsel IP in Jakarta. Traditional detection: pass.

Layered detection:

1. IP check: residential Indonesian IP → pass
2. Fingerprint check: iPhone UA but Intel GPU → +40
3. Behavior check: no touch events on "mobile" → +15
4. Timing check: request arrived 200ms after page load → +25
5. Velocity check: this fingerprint seen 3x in last minute → +20
6. Total: 100 points → block

The IP was clean. Everything else wasn't.

The Reality Check

No detection system catches 100% of fraud. Residential proxies combined with sophisticated browser automation can pass many checks. The goal isn't perfection—it's making fraud expensive enough that attackers move to easier targets.

What we've found: layered behavioral detection catches 85-90% of residential proxy traffic that IP-based detection misses. The remaining 10-15% requires ongoing adaptation as fraud techniques evolve.

If you're still relying primarily on IP blocklists, you're missing the majority of modern fraud. The traffic looks legitimate at the network layer. You have to look deeper.