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. 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 on its own it misses proxy-routed fraud. 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
Most exclusion lists are built the same way: spot a suspicious address in the reports, add it, repeat. That works against traffic from data centers, which sits on hosting networks you can recognize and block. It works far less well against traffic routed through 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. Our Google Ads bot traffic guide covers the automated side of the same problem.
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 over 600 apps, backed by roughly 7,400 servers and over 3,000 unique Windows file hashes, and sold under a set of proxy and 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 lesson for advertisers is about the model, not one network. Google says the SDKs give operators "the millions of devices they need", and other residential proxy pools keep running after any single takedown. At the IP level they look the same as real users, and no static exclusion list can keep up with a pool that size.
Why static blocklists are structurally outmatched
There are three concrete reasons a list of IPs can't win this fight:
- Rotation. Residential proxy networks draw on huge pools of consumer devices and cycle exit IPs constantly. 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 you want to exclude. Five hundred slots against a rotating pool of home 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 apply across the account, including Performance Max, but they're still a list of addresses with the same rotation problem.
Google's invalid traffic page describes automated filters that look for interactions that don't match normal human behavior. Residential proxies are built so the network side of a click looks like a normal home user, which leaves the device and the session to give the fraud away.
GIVT vs. SIVT: the standard that explains why lists fall short
The advertising industry already has language for this. The Media Rating Council's invalid traffic standard splits it into two tiers. General Invalid Traffic (GIVT) is traffic "identified through routine means of filtration executed through application of lists or with other standardized parameter checks": known bots, crawlers, and bad IP lists. Sophisticated Invalid Traffic (SIVT) covers "more difficult to detect situations that require advanced analytics, multi-point corroboration/coordination, significant human intervention, etc."
Residential-proxy and malware-driven click fraud is SIVT by definition. A blocklist is, by the standard's own wording, filtration "through application of lists", a GIVT tool. It is categorically the wrong instrument for SIVT. That's the precise, industry-standard reason IP blocking only catches part of your invalid traffic.
The conversion blind spot blocklists ignore
There's a second gap even when a click is filtered. Google's invalid traffic page says that because you capture leads on your own website and CRM, "bots or users can still submit forms even if Google identifies the ad interaction as invalid." The same page says Google "removes some invalid conversions if they originate from invalid traffic", which is not all of them. And Google's invalid clicks definition notes that when a click leads to a conversion and is later filtered out, "Google removes the invalid click from campaign metrics, but the valid conversion remains." Google counts that conversion as valid, but if the click behind it was fraud, the form fill may be junk too. It lands in your conversion data and feeds Smart Bidding and Performance Max. The reliable fix is stopping more fraudulent clicks before they reach your form, and a list of known IPs only does that for addresses you have already caught.
What device and behavioral detection add on top of IP lists
If the IP can't be trusted, you detect the actor instead. Three layers survive a rotating residential IP:
-
Device fingerprinting. A derived identity assembled from hardware, software, and network attributes 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 every click on 100+ device, network and behavior data points, not on IP reputation alone. Its fingerprinting re-identifies a fraudulent visitor even when the exit IP changes.
-
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.
-
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; connection timing that suggests the traffic is being relayed through another country. ClickFortify scores every click on 100+ device, network and behavior data points, so a session whose signals contradict each other 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 and Display. For Google Ads click fraud protection, ClickFortify scores every click on 100+ device, network and behavior data points in real time and excludes invalid IPs automatically through Google Ads IP exclusion lists, with an evidence trail for each block. Google caps campaign IP exclusions at 500 addresses, which is why list-based blocking alone falls short and the per-click scoring matters.
- Performance Max. Google says campaign-level IP exclusions aren't available for Performance Max, while account-level IP exclusions apply across the account, including Performance Max. IP-based protection on PMax therefore runs through account-level exclusions.
- Conversion data. Because bots can still submit forms after Google flags the interaction, the goal on Google Ads is fewer fraudulent clicks reaching your forms. ClickFortify works at the click and IP level there, so less junk reaches your conversion data. It does not edit or remove conversions inside Google Ads.
- Meta. Meta has no IP blocking, so ClickFortify scores each landing-page visit and acts through the controls Meta does offer. It can switch off Audience Network on ad sets where fraud is detected (opt-in per ad account) and send the publishers you block to Meta's block list. When the CAPI proxy is enabled, conversions are checked against the visitor's fraud score, and flagged events are dropped or tagged before Meta receives them.
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. Proxy-routed click fraud 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 it 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.
