Por que o bloqueio de IP não pega fraude de proxy residencial

Você fez tudo certo. Tirou os endereços IP suspeitos dos seus termos de pesquisa e do analytics, adicionou-os à sua lista de exclusão, talvez até tenha esbarrado no teto de 500 endereços do Google, e os cliques inúteis e os leads falsos continuaram chegando. Não foi um erro seu. O motivo tem nome: proxies residenciais. Eles roteiam a fraude de cliques por endereços IP domésticos reais, atribuídos por provedores, que parecem idênticos aos seus melhores clientes, o que significa que uma lista de bloqueio estática não consegue vê-los. O bloqueio de IP ainda é necessário, mas sozinho ele deixa passar a fraude roteada por proxy. Este guia explica o mecanismo, por que as listas de bloqueio estão estruturalmente em desvantagem e o que a detecção por dispositivo e comportamento acrescenta.

A lista de bloqueio que você montou no mês passado já está obsoleta

A maioria das listas de exclusão é montada do mesmo jeito: você identifica um endereço suspeito nos relatórios, adiciona e repete. Isso funciona contra o tráfego de data centers, que fica em redes de hospedagem que você consegue reconhecer e bloquear. Funciona bem menos contra o tráfego roteado por conexões residenciais que parecem exatamente usuários genuínos.

A conclusão honesta a que a maioria dos anunciantes chega da forma mais difícil: uma lista de IPs ruins é uma foto de um alvo que já se moveu. Quando você identifica e exclui um endereço, o operador da fraude já está em outro. A solução não é uma lista maior; é uma camada diferente de detecção.

O que é, de fato, um proxy residencial

Um proxy residencial roteia o tráfego pela conexão de internet de um consumidor real. O IP de saída pertence a uma residência ou a uma pequena empresa em uma linha comum de banda larga ou móvel, não a um provedor de hospedagem. Os operadores montam essas redes embutindo SDKs em apps móveis gratuitos, extensões de navegador e VPNs “gratuitas” que revendem silenciosamente a banda do usuário, muitas vezes sem consentimento significativo.

Esse detalhe é tudo. Quando um clique fraudulento sai de um proxy residencial, ele chega carregando a reputação de IP confiável de uma conexão doméstica real. Ele não aparece em nenhuma lista de bloqueio de data center, porque não é um data center. E bloqueá-lo de vez é perigoso: atrás dessa mesma faixa de IP estão clientes reais que você quer. O tráfego de data center e de VPN é relativamente fácil de pontuar; o tráfego de proxy residencial é projetado especificamente para derrotar as verificações que pegam esses dois. Nosso guia sobre tráfego de bots no Google Ads trata do lado automatizado do mesmo problema.

A prova de 2026: a desarticulação da IPIDEA pelo Google

Isso não é teoria. Em 29 de janeiro de 2026, o Threat Intelligence Group do Google anunciou que havia desarticulado a IPIDEA, uma das maiores redes de proxies residenciais do mundo. A escala é a notícia: a rede era alimentada por SDKs escondidos em mais de 600 apps, sustentada por cerca de 7.400 servidores e mais de 3.000 hashes únicos de arquivos do Windows, e comercializada sob um conjunto de marcas de proxy e VPN apresentadas como independentes. Em uma única janela de sete dias naquele mês, o Google observou mais de 550 grupos de ameaças distintos usando nós de saída da IPIDEA.

A própria explicação do Google sobre por que esse tráfego é tão difícil de parar soa como uma acusação contra o bloqueio de IP: “Ao rotear o tráfego por uma série de dispositivos de consumidores no mundo todo, os atacantes conseguem mascarar sua atividade maliciosa sequestrando esses endereços IP.”

A lição para os anunciantes é sobre o modelo, não sobre uma rede específica. O Google diz que os SDKs dão aos operadores “os milhões de dispositivos de que precisam”, e outros conjuntos de proxies residenciais continuam funcionando depois da queda de qualquer rede isolada. No nível do IP, eles parecem iguais a usuários reais, e nenhuma lista de exclusão estática acompanha um conjunto desse tamanho.

Por que as listas de bloqueio estáticas estão estruturalmente em desvantagem

Há três motivos concretos pelos quais uma lista de IPs não consegue vencer essa luta:

• Rotação. As redes de proxies residenciais se apoiam em enormes conjuntos de dispositivos de consumidores e trocam os IPs de saída o tempo todo. Uma defesa que funciona enumerando endereços ruins está jogando um jogo que matematicamente não consegue terminar.
• Os limites rígidos do Google. O Google Ads permite excluir até 500 endereços IP por campanha e exige que você liste todas as versões de um endereço que quer excluir. Quinhentas vagas contra um conjunto rotativo de IPs domésticos não é uma disputa.
• Lacunas de cobertura. Segundo a mesma documentação do Google, as exclusões de IP no nível da campanha “não estão disponíveis para campanhas de vídeo, campanhas de hotel, campanhas de app, campanhas Performance Max e campanhas de Display inteligente”. As exclusões no nível da conta valem para a conta toda, inclusive o Performance Max, mas continuam sendo uma lista de endereços, com o mesmo problema de rotação.

A página de tráfego inválido do Google descreve filtros automatizados que procuram interações que não combinam com o comportamento humano normal. Os proxies residenciais são construídos para que o lado de rede de um clique pareça o de um usuário doméstico comum, o que deixa para o dispositivo e para a sessão a tarefa de entregar a fraude.

GIVT x SIVT: o padrão que explica por que as listas ficam aquém

O setor de publicidade já tem vocabulário para isso. O padrão de tráfego inválido do Media Rating Council divide o tráfego em dois níveis. O tráfego inválido geral (GIVT) é o tráfego “identificado por meios rotineiros de filtragem executados pela aplicação de listas ou de outras verificações de parâmetros padronizadas”: bots conhecidos, crawlers e listas de IPs ruins. O tráfego inválido sofisticado (SIVT) abrange “situações mais difíceis de detectar, que exigem análises avançadas, corroboração/coordenação em vários pontos, intervenção humana significativa etc.”

A fraude de cliques movida por proxies residenciais e malware é SIVT por definição. Uma lista de bloqueio é, nas palavras do próprio padrão, filtragem “pela aplicação de listas”, uma ferramenta de GIVT. Ela é, por categoria, o instrumento errado para o SIVT. Esse é o motivo preciso, segundo o padrão do setor, pelo qual o bloqueio de IP pega só parte do seu tráfego inválido.

O ponto cego das conversões que as listas de bloqueio ignoram

Existe uma segunda falha mesmo quando um clique é filtrado. A página de tráfego inválido do Google diz que, como você captura leads no seu próprio site e CRM, “bots ou usuários ainda podem enviar formulários mesmo que o Google identifique a interação com o anúncio como inválida”. A mesma página diz que o Google “remove algumas conversões inválidas se elas se originarem de tráfego inválido”, o que não significa todas. E a definição de cliques inválidos do Google observa que, quando um clique leva a uma conversão e depois é filtrado, “o Google remove o clique inválido das métricas da campanha, mas a conversão válida permanece”. O Google conta essa conversão como válida, mas, se o clique por trás dela foi fraude, o envio do formulário também pode ser lixo. Ele cai nos seus dados de conversão e alimenta o Smart Bidding e o Performance Max. A solução confiável é barrar mais cliques fraudulentos antes que cheguem ao seu formulário, e uma lista de IPs conhecidos só faz isso com os endereços que você já pegou.

O que a detecção por dispositivo e comportamento acrescenta às listas de IP

Se não dá para confiar no IP, você detecta o agente. Três camadas sobrevivem a um IP residencial em rotação:

1. Impressão digital do dispositivo. Uma identidade derivada, montada a partir de atributos de hardware, software e rede, que reidentifica o mesmo visitante mesmo com cookies apagados, navegação privada e IPs novinhos. Quando a fraude chega por um IP residencial em rotação que nunca apareceria em uma lista de bloqueio, a ClickFortify pontua cada clique com mais de 100 pontos de dados de dispositivo, rede e comportamento, e não só pela reputação do IP. Sua impressão digital reidentifica um visitante fraudulento mesmo quando o IP de saída muda.

2. Sinais comportamentais. Pessoas reais movem o mouse, rolam a página, hesitam e navegam de jeitos humanos e bagunçados. Clientes automatizados não, e ferramentas de navegador headless como Selenium, Puppeteer e Playwright deixam impressões digitais de automação detectáveis. Ao analisar o comportamento pós-clique (tempo de permanência, profundidade de rolagem, fluxo de navegação e esses indícios de automação), a ClickFortify sinaliza cliques que passam em uma verificação de reputação de IP, mas se comportam como bots.

3. Corroboração entre sinais. Os indícios mais fortes vêm das contradições. Um IP residencial com uma impressão digital de dispositivo típica de data center; um fuso horário ou idioma do navegador que não bate com a geolocalização do IP; tempos de conexão que sugerem que o tráfego está sendo retransmitido por outro país. A ClickFortify pontua cada clique com mais de 100 pontos de dados de dispositivo, rede e comportamento, então uma sessão cujos sinais se contradizem é exposta em vez de receber confiança. A detecção de proxy, data center e VPN continua importando aqui: não como veredito isolado, mas como uma entrada ponderada entre muitas.

Como a ClickFortify organiza a defesa em camadas no Google, no PMax e na Meta

Costurar essas camadas é o trabalho de verdade, e ele precisa respeitar as restrições de cada plataforma:

• Google Pesquisa e Display. Para a proteção contra fraude de cliques no Google Ads, a ClickFortify pontua cada clique com mais de 100 pontos de dados de dispositivo, rede e comportamento em tempo real e exclui IPs inválidos automaticamente pelas listas de exclusão de IP do Google Ads, com uma trilha de evidências para cada bloqueio. O Google limita as exclusões de IP por campanha a 500 endereços, e é por isso que o bloqueio baseado só em listas fica aquém e a pontuação por clique faz diferença.
• Performance Max. O Google diz que as exclusões de IP no nível da campanha não estão disponíveis para o Performance Max, enquanto as exclusões de IP no nível da conta valem para a conta toda, inclusive o Performance Max. A proteção baseada em IP no PMax, portanto, passa pelas exclusões no nível da conta.
• Dados de conversão. Como os bots ainda podem enviar formulários depois que o Google sinaliza a interação, o objetivo no Google Ads é que menos cliques fraudulentos cheguem aos seus formulários. A ClickFortify atua no nível do clique e do IP, para que menos lixo chegue aos seus dados de conversão. Ela não edita nem remove conversões dentro do Google Ads.
• Meta. A Meta não tem bloqueio de IP, então a ClickFortify pontua cada visita à página de destino e age pelos controles que a Meta oferece. Ela pode desativar a Audience Network nos conjuntos de anúncios em que fraude é detectada (opcional por conta de anúncios) e enviar os publishers que você bloqueia para a lista de bloqueio da Meta. Com o proxy CAPI ativado, as conversões são conferidas com a pontuação de fraude do visitante, e eventos sinalizados são descartados ou marcados antes de chegarem à Meta.

A conclusão

Mantenha suas exclusões de IP; elas são uma primeira camada necessária e param o tráfego pouco sofisticado, baseado em listas, que os padrões chamam de GIVT. Mas entenda o que elas não conseguem fazer. A fraude de cliques roteada por proxy usa conexões residenciais reais que giram mais rápido do que qualquer lista consegue acompanhar, escapa das verificações de data center e polui seus dados de conversão mesmo quando o clique é pego. Pegá-la exige identificar o agente (por dispositivo e comportamento), não o endereço. Essa abordagem em camadas, aplicada de forma consistente em Pesquisa, Performance Max e Meta, é a diferença entre uma lista de bloqueio que fica obsoleta em uma semana e uma proteção que segue a fraude aonde quer que venha o próximo IP.