Why IP Blocklists Miss Half Your Click Fraud (2026)

You did everything right. You pulled the suspicious IP addresses out of your search terms and analytics, added them to your exclusion list, maybe even bumped against Google's 500-address ceiling — and the junk clicks and fake leads kept coming. This isn't a mistake on your part. In 2026, the reason has a name: residential proxies. They route click fraud through real, ISP-assigned home IP addresses that look identical to your best customers, which means a static blocklist can't see them. IP blocking is still necessary — but it now catches only about half the problem. This guide explains the mechanism, why blocklists are structurally outmatched, and what device and behavioral detection add on top.

The blocklist you built last month is already obsolete

Two facts from 2026 frame the whole problem. First, automated traffic now makes up 53% of all web traffic, with humans down to 47%, according to Imperva's 2026 Bad Bot Report. Second, a large and growing share of that bad traffic no longer comes from data centers you can recognize and block — it comes from residential connections that look exactly like genuine users.

The honest takeaway most advertisers reach the hard way: a list of bad IPs is a snapshot of a target that has already moved. By the time you've identified and excluded an address, the fraud operator is on a different one. The fix isn't a bigger list — it's a different layer of detection.

What a residential proxy actually is

A residential proxy routes traffic through a real consumer's internet connection. The exit IP belongs to a household or a small business on a normal broadband or mobile line — not a hosting provider. Operators build these networks by embedding SDKs in free mobile apps, browser extensions, and "free" VPNs that quietly resell the user's bandwidth, often without meaningful consent.

That detail is everything. When a fraudulent click leaves a residential proxy, it arrives carrying the trustworthy IP reputation of a real home connection. It doesn't appear on any datacenter blocklist, because it isn't a data center. And blocking it outright is dangerous: behind that same IP range are real customers you want. Datacenter and VPN traffic is comparatively easy to score; residential-proxy traffic is engineered specifically to defeat the checks that catch them.

The 2026 proof: Google's IPIDEA takedown

This isn't theoretical. On January 29, 2026, Google's Threat Intelligence Group announced it had disrupted IPIDEA, one of the largest residential proxy networks in the world. The scale is the story: the network was fueled by SDKs hidden in 600+ Android apps, backed by roughly 7,400 servers and over 3,000 unique Windows file hashes, and marketed under 13 proxy/VPN brands presented as independent. In a single seven-day window that month, Google observed more than 550 distinct threat groups using IPIDEA exit nodes.

Google's own explanation of why this traffic is so hard to stop reads like an indictment of IP blocking: "By routing traffic through an array of consumer devices all over the world, attackers can mask their malicious activity by hijacking these IP addresses." The overlaps between exit nodes make attribution itself difficult.

And this is the residential-ISP share of bad traffic that independent researchers keep measuring: Imperva attributed roughly a quarter of bad-bot traffic to residential ISPs in its 2024 report and found 21% of bot attacks using residential proxies in 2025. Even after a takedown the size of IPIDEA, the surviving pool is too large — and too indistinguishable from real users — for any static exclusion list to keep up.

Why static blocklists are structurally outmatched

There are three concrete reasons a list of IPs can't win this fight:

• Rotation. Residential proxy networks cycle through millions of distinct exit IPs. A defense that works by enumerating bad addresses is playing a game it mathematically can't finish.
• Google's hard caps. Google Ads lets you exclude up to 500 IP addresses per campaign and requires you to list every version of an address (both IPv4 and IPv6). Five hundred slots against millions of rotating IPs is not a contest.
• Coverage gaps. Per the same Google documentation, campaign-level IP exclusions "aren't available for video campaigns, hotel campaigns, App campaigns, Performance Max campaigns, and Smart Display campaigns." Account-level exclusions do reach Performance Max — but they're still bound by the same per-campaign limit and the same rotation problem.

Notably, Google's invalid-traffic filtering explicitly names data-center traffic as a category it screens for. Residential proxies exist precisely so the traffic doesn't look like that.

GIVT vs. SIVT: the standard that proves "only half"

The advertising industry already has language for this. The IAB and Media Rating Council split invalid traffic into two tiers. General Invalid Traffic (GIVT) is the kind "identified through routine and list-based means of filtration" — known bots, crawlers, and bad IP lists. Sophisticated Invalid Traffic (SIVT) is "more difficult to detect" and requires "advanced analytics, multi-point corroboration, and/or significant human intervention."

Residential-proxy and malware-driven click fraud is SIVT by definition. A blocklist is, by the standard's own wording, a list-based means of filtration — a GIVT tool. It is categorically the wrong instrument for the half of the problem that matters most. That's the precise, industry-standard reason IP blocking only catches part of your invalid traffic. For context on how big that part is, Pixalate's Q1 2025 benchmarks put invalid-traffic rates at 18% on desktop and mobile web and 31% on mobile app.

The conversion blind spot blocklists ignore

There's a second failure even when a click is filtered. Google notes that when a click is judged invalid and removed, the conversion attributed to that click may not be removed. So a fraudulent action can survive click filtering and still land in your conversion data — where it feeds Smart Bidding and Performance Max, teaching the algorithm to spend more chasing the exact audiences and placements that produce junk. IP-level defenses do nothing about this. It's a separate layer entirely.

What device and behavioral detection add — the other half

If the IP can't be trusted, you detect the actor instead. Three layers survive a rotating residential IP:

1. Device fingerprinting. A derived identity assembled from hardware, software, and network attributes — without storing anything on the device — that re-identifies the same visitor across cleared cookies, private browsing, and brand-new IPs. When fraud arrives on a rotating residential IP that would never appear on a blocklist, ClickFortify scores it on device and behavioral signals as well as IP reputation, so the same actor is caught even after the IP changes. Its fingerprinting builds an identity that survives cookie clearing and re-identifies a fraudulent visitor across hundreds of different residential exit IPs.

2. Behavioral signals. Real people move a mouse, scroll, hesitate, and navigate in messy human ways. Automated clients don't — and headless-browser tools like Selenium, Puppeteer, and Playwright leave detectable automation fingerprints. By analyzing post-click behavior — dwell time, scroll depth, navigation flow, and those automation tells — ClickFortify flags clicks that pass an IP-reputation check but behave like bots.

3. Cross-signal corroboration. The strongest tells come from contradictions. A residential IP carrying a datacenter-class device fingerprint; a browser timezone or language that doesn't match the IP's geolocation; latency and timing that betray proxied routing through another country. ClickFortify cross-checks IP-to-device and geo-consistency signals, so a mismatched session is surfaced rather than trusted. Proxy, datacenter, and VPN detection still matters here — not as a verdict on its own, but as one weighted input among many.

How ClickFortify layers the defense across Google, PMax, and Meta

Stitching these layers together is the actual job, and it has to respect each platform's constraints:

• Google Search & Display. ClickFortify auto-excludes confirmed fraudulent IPs in real time and manages the exclusion list dynamically against Google's 500-IP-per-campaign ceiling, so a finite list isn't wasted on stale addresses while fresh ones go unblocked.
• Performance Max. Because campaign-level exclusions can't touch PMax, ClickFortify applies account-level exclusions plus off-platform behavioral detection, so PMax spend isn't left undefended against proxy traffic.
• Conversions & Smart Bidding. Since a filtered click can still leave a polluting conversion behind, ClickFortify adds conversion and CAPI-level filtering so fraud-driven conversions don't train Smart Bidding to chase junk.
• Meta. Where raw client IPs can't be excluded at all, ClickFortify feeds visitors it identifies as fraudulent into Custom Audience exclusions and CAPI filtering, extending behavioral protection to a platform with no native IP controls.

The takeaway

Keep your IP exclusions — they're a necessary first layer, and they stop the unsophisticated, list-based traffic the standards call GIVT. But understand what they can't do. The expensive, persistent half of click fraud now rides real residential connections that rotate faster than any list can track, slips past datacenter checks, and pollutes your conversion data even when the click is caught. Catching that half requires identifying the actor — by device and behavior — not the address. That layered approach, applied consistently across Search, Performance Max, and Meta, is the difference between a blocklist that's obsolete in a week and protection that follows the fraud wherever its next IP comes from.