Você configurou seu antidetect até o último parâmetro. Canvas único, WebGL honesto, fontes discretas, fusos horários separados, cookies limpos. Mesmo assim, a conta enfrenta captcha a cada passo e, um dia depois, leva ban. Situação familiar? A primeira coisa que fazemos é culpar a fingerprint: revisamos o conjunto de entropia, mexemos nas versões do navegador, trocamos o user-agent. Às vezes, ajuda. Mas, frequentemente, o problema está em outra área, e vale a pena investigá-la antes de se aprofundar nas nuances da impressão digital.

Existe um fato desagradável que muitos descobrem com o próprio dinheiro: o site pode formar uma opinião sobre você antes mesmo de ver seu navegador. Não por cookies, nem por impressão digital, nem por comportamento. Apenas pelo endereço IP de onde veio a requisição. A verificação leva milissegundos e acontece no estágio mais inicial do processamento da conexão. Se o endereço é conhecido como problemático, não importa o quão limpo seu perfil foi configurado.

Neste artigo, vamos entender como funcionam as blocklists públicas, por que proxies baratos passam anos nelas, como um IP móvel é fundamentalmente diferente e como verificar seus endereços antes que eles comecem a queimar contas. Escrevemos com calma, com números reais e um exemplo prático de resposta de API, sem prometer burlar sites específicos nem usar superlativos.

Por que o ban chega antes do que você imagina

O cenário típico é assim: você inicia a sessão, abre o site desejado e, em vez do conteúdo, recebe um 403 ou um captcha infinito. A lógica sugere procurar a causa nas configurações recentes do navegador. Mas vamos analisar a sequência de eventos em ordem.

Quando o navegador estabelece a conexão, o servidor recebe o endereço IP de origem antes de enviar qualquer byte de conteúdo. Nesse estágio, o sistema antifraude pode consultar listas de reputação internas e externas. Muitas dessas listas são públicas e atualizadas diariamente. Se o seu endereço estiver nelas, o site já começa a desconfiar de você. A partir daí, os eventos seguem um de dois caminhos:

  • Desconfiança elevada. Você vê captchas, limites de frequência de ações, exigência de confirmação por telefone. A conta vive, mas cada passo vira uma luta.
  • Recusa direta. 403 na entrada, bloqueio imediato de cadastro, shadowban no perfil recém-criado. O navegador nem chega à interação real.

Ponto-chave: a fingerprint é verificada depois. Primeiro, a rede. E, se você passa anos refinando sua impressão digital, mas usa endereços de um pool compartilhado, está otimizando a segunda etapa enquanto falha na primeira. Daí a conclusão prática, à qual voltaremos: a reputação do IP deve ser verificada antes do uso, não depois do primeiro ban.

Como funcionam as blocklists públicas

Existe um ecossistema inteiro de feeds abertos — listas de endereços IP atualizadas regularmente, agrupadas por tipo de ameaça. Originalmente, foram criados para segurança de rede: administradores os conectam a firewalls para bloquear scanners, bots de spam e fontes conhecidas de ataques. Mas, como as listas são públicas, qualquer pessoa pode usá-las, inclusive o antifraude dos sites-alvo.

Dentro desse ecossistema, há um grupo específico de feeds que catalogam exatamente proxies abertos, nós de anonimização e serviços semelhantes. Vamos citar arquivos concretos para tornar a conversa mais objetiva:

  • firehol_proxies.netset — conjunto agregado de endereços vistos como proxies abertos.
  • socks_proxy.ipset — lista de proxies SOCKS, disponível em recortes temporais de 1, 7 e 30 dias.
  • sslproxies.ipset — catálogo de proxies SSL.
  • tor_exits.ipset — nós de saída de redes de anonimização.

Observe os recortes de 1/7/30 dias do socks_proxy. Isso significa que o endereço é registrado não uma vez, mas com histórico. Mesmo que o proxy tenha parado de responder hoje, ele ainda aparece nos recortes semanal e mensal. Para o antifraude, isso é conveniente: uma marca recente pega endereços ativos, enquanto os recortes históricos bloqueiam quem tenta esperar passar o tempo.

No projeto IPGuardian, agregamos esse ecossistema por completo. Números atuais para 2026: 162 fontes de blocklists, 8 categorias, atualização diária. A categoria “anonymizers” reúne 17 fontes e contém 4,88 milhões de endereços — é a maior categoria da base. Para comparação: a categoria abuse tem cerca de 1,6 milhão de endereços, e attacks, aproximadamente 497 mil. Há mais anonymizers do que abuse e attacks juntas.

Somando todas as categorias, são 7,11 milhões de IPs individuais, além de 356 mil sub-redes, o que resulta em mais de 2,1 bilhões de endereços cobertos. A confiabilidade da atualização é de 94,4% de sincronizações bem-sucedidas no mês. Não é uma vitrine abstrata de números, mas o volume de dados com o qual qualquer pessoa que conectou feeds abertos ao seu antifraude precisa lidar.

Demonstração: pegamos um endereço de uma lista gratuita

Teoria é bom, mas vamos ver uma resposta real. Pegamos um endereço que está em uma lista pública de proxies e o submetemos à verificação. A requisição é extremamente simples:

curl -X POST https://ipguardian.net/api/check -H "Content-Type: application/json" -d '"1.20.254.32"'

Resposta (resumida):

  • "found": true
  • {"filename": "socks_proxy.ipset", "category": "anonymizers"}
  • {"filename": "socks_proxy_7d.ipset", "category": "anonymizers"}
  • {"filename": "firehol_proxies.netset", "category": "anonymizers"}
  • {"filename": "stopforumspam.ipset", "category": "abuse"}

Vamos analisar o que vemos. O campo found: true já diz que o endereço é conhecido. Depois vem a lista de fontes. As três primeiras linhas são esperadas — são marcas de anonymizers. O endereço aparece como proxy SOCKS no recorte recente e no semanal, e também no conjunto agregado de proxies abertos. Nada surpreendente: ele é, de fato, um proxy de uma lista aberta.

Agora veja a última linha. stopforumspam.ipset, categoria abuse. Isso não é mais “proxy”. É uma marca de fonte de spam. O endereço entrou na base de uma plataforma que coleta dados sobre cadastros de spam e abusos em fóruns. Ou seja, através desse IP, alguém não apenas navegou anonimamente, mas realizou ações que receberam o rótulo de abuse.

E aqui começa a diferença mais importante, que vale a pena acompanhar daqui em diante.

Dois rótulos diferentes, dois destinos diferentes para a conta

As marcas nas blocklists não são equivalentes. Para o antifraude, há uma grande diferença entre “isso é um proxy” e “isso é uma fonte de abusos”.

Rótulo “marcado como proxy”

A categoria anonymizers diz ao site: a conexão passa por um nó intermediário, a origem real está oculta. A reação costuma ser moderada — desconfiança elevada. Você verá captcha, pedidos de confirmação, limites de ações. É chato, mas ainda dá para trabalhar. Muitos usuários legítimos acessam por gateways corporativos, e cortar totalmente esse tráfego seria arriscado para o próprio site.

Rótulo “marcado como spam/abuse”

As categorias abuse e spam são outra história. Aqui, o site vê não apenas ocultação, mas um histórico de ações maliciosas vindas daquele endereço. A reação é mais dura: bloqueio imediato, recusa de cadastro, ban na entrada. A lógica é simples — desse IP já vieram coisas ruins, por que arriscar de novo?

O problema dos proxies baratos é que eles acumulam os dois rótulos ao mesmo tempo. Por um proxy público ou compartilhado, todo mundo passa durante anos: quem faz scraping, quem envia spam, quem cria farms de bots, quem espalha lixo em fóruns. Cada uma dessas ações deixa um rastro, e o endereço acumula marcas de várias categorias.

Os piores endereços da nossa base estão em 32 listas simultaneamente — nas categorias abuse, anonymizers, attacks e spam. Imagine usar um endereço desses para uma conta nova. O site vê a conexão, consulta as listas em milissegundos, encontra um buquê de marcas problemáticas e fecha a porta antes que seu antidetect perfeitamente configurado desenhe a primeira página. Nesse momento, a barateza do proxy se traduz em conta queimada, tempo perdido no aquecimento e, no caso de mídia paga, verba desperdiçada.

O que torna o IP móvel fundamentalmente diferente

Agora o ponto-chave: por que os endereços móveis funcionam de outra forma. Não é mágica, é arquitetura de redes celulares.

A operadora distribui endereços IP aos assinantes via tecnologia CGNAT. Por trás de um único endereço público da operadora estão centenas de assinantes reais — pessoas comuns com smartphones que rolam feeds, pagam contas, usam mensageiros e marketplaces. É tráfego humano real, diverso e legítimo.

Daí a principal consequência: a operadora não disponibiliza seu endereço como proxy aberto. Ele não está no socks_proxy.ipset, nem no firehol_proxies.netset, nem em catálogos de anonymizers — simplesmente porque não é um proxy público por natureza. Scanners que procuram portas de proxies abertos não encontram esse endereço e não o incluem nas listas.

Além disso, o site tem um forte incentivo econômico para não bloquear esses endereços por inteiro. Bloquear o IP móvel de uma operadora significa cortar, de uma vez, centenas de clientes reais que compartilham o mesmo endereço naquele momento. Para a plataforma, é perda direta de usuários vivos e de dinheiro. Por isso, o antifraude trata os endereços móveis com mais cuidado, por definição.

É exatamente por isso que os proxies móveis mostram outra dinâmica no trabalho com contas: você está no meio do tráfego real, não em um pool comum de anonymizers com histórico de abusos.

Ressalva importante: IP móvel não é uma armadura

Aqui somos obrigados a ser honestos, e essa ressalva fortalece o material, não o enfraquece. O IP móvel também pode cair em listas de spam ou abuse. Se algum assinante no mesmo endereço CGNAT aprontou — enviou spam, invadiu contas alheias, fez atividade maliciosa — o endereço recebe a marca de abuse. A categoria anonymizers provavelmente será evitada, mas spam/abuse pode ocorrer perfeitamente.

Disso decorre uma conclusão prática direta, e não um final benevolente de “use proxies móveis e durma tranquilo”. São necessárias duas coisas:

  • Verificação antes do uso. Antes de colocar o endereço em ação, consulte as listas. Móvel ou não, se houver marca de abuse, é melhor saber antes do que depois do ban.
  • Rotação. Capacidade de trocar de endereço se o atual estiver manchado por atividade alheia. As redes móveis permitem trocar de IP, e isso é uma proteção embutida contra erros de terceiros.

Nenhum tipo de proxy dá garantia de 100%. A diferença está nas probabilidades e em você ter ferramentas de controle. Endereços móveis têm probabilidade quase nula de cair no pool de anonymizers por razões arquiteturais, e o risco de abuse é gerenciável com verificação e rotação.

Na prática: como verificar seus endereços

Vamos ao que mais importa: como integrar a verificação de reputação ao seu fluxo de trabalho. Boa notícia: para uma verificação básica, não é preciso registrar-se nem ter chave de API.

Verificação única com curl

O cenário mais simples é verificar um endereço antes de iniciar o perfil:

  1. Envie uma requisição POST para o endpoint /api/check.
  2. No corpo, envie o endereço IP como string em formato JSON.
  3. Leia a resposta: o campo found, o array sources com nomes de arquivos e categorias.

Comando:

curl -X POST https://ipguardian.net/api/check -H "Content-Type: application/json" -d '"SEU_IP"'

Se found for false, o endereço não consta em listas conhecidas — bom sinal. Se for true, veja em quais categorias. A marca anonymizers é tolerável para muitas tarefas; a marca abuse ou spam é motivo para deixar o endereço de lado.

Verificação em lote de até 100 endereços

Quando você tem um pool com dezenas de endereços, verificar um a um é inviável. O serviço aceita até 100 endereços por requisição. A velocidade de resposta é de 4–5 ms por endereço, ou seja, um pool de cem endereços é verificado em alguns centésimos de segundo. Isso permite integrar a verificação diretamente ao pipeline, sem criar gargalo.

Algoritmo típico de verificação em lote:

  1. Monte a lista de endereços que pretende usar (até 100 por requisição).
  2. Envie todos em uma única requisição POST para o endpoint de verificação.
  3. Analise a resposta: para cada endereço haverá found e a lista de fontes.
  4. Filtre os endereços com marcas de abuse e spam — não os use.
  5. Endereços limpos ou apenas com marcas leves vão para a rotação.

Como ler a resposta

Três campos são realmente necessários:

  • found — valor booleano. true significa que o endereço foi encontrado em pelo menos uma lista.
  • category — tipo de ameaça. anonymizers, abuse, spam, attacks, etc. Pela categoria, você entende a gravidade do problema.
  • filename — nome da fonte específica. Útil para entender se a marca é recente. Por exemplo, socks_proxy.ipset versus socks_proxy_7d.ipset indica atualidades diferentes.

Casos de uso: cinco cenários práticos

Vejamos como a verificação de reputação se encaixa em tarefas específicas. Para cada cenário: para quem, por que e como.

Cenário 1. Verificação pré-lançamento em multiacting

Para quem: pessoas que gerenciam dezenas ou centenas de perfis em navegadores antidetect.

Por quê: descartar endereços manchados antes de criar a conta, para não queimar perfis aquecidos em uma rede ruim.

Como: antes de vincular o proxy ao perfil, passe o endereço pela verificação. Se houver abuse ou spam, não use esse endereço para uma conta importante. Uma regra simples economiza horas de trabalho tentando reverter bans. Dica: tenha um script curto que verifique o endereço no momento da atribuição ao perfil e destaque marcas problemáticas.

Cenário 2. Higiene de pool para scraping

Para quem: especialistas em coleta de dados.

Por quê: endereços com marca de anonymizers enfrentam mais captcha, o que prejudica a estabilidade do scraping e aumenta os custos de processamento de captcha.

Como: antes de uma grande sessão, verifique todo o pool em lote. Divida os endereços em três grupos: limpos (prioridade), marcas leves (reserva), abuse/spam (descarte). Trabalhe principalmente no grupo limpo, mantendo velocidade de requisições em limites razoáveis.

Cenário 3. Diagnóstico de aumento repentino de bans em mídia paga

Para quem: profissionais de tráfego pago.

Por quê: quando uma estratégia para de funcionar de repente, é importante descobrir rápido se o problema é criativo, conta ou rede.

Como: diante de um pico de bans, verifique os endereços primeiro. Se eles acumularam marcas de abuse — o problema está aí, não nos criativos. Isso economiza verba que, de outra forma, seria gasta em testes intermináveis de anúncios. Dica de bastidor: registre o histórico de verificações para ver quando exatamente o endereço foi corrompido.

Cenário 4. Avaliação de novos proxies do fornecedor

Para quem: todos que compram proxies.

Por quê: verificar a qualidade do pool antes de pagar ou imediatamente após obter acesso.

Como: ao receber acesso de teste, passe os endereços fornecidos pela verificação em lote. Uma alta proporção de marcas anonymizers e abuse no pool é um sinal de que você está pagando por um pool compartilhado. É um critério objetivo em vez de promessas do vendedor.

Cenário 5. Rotação automática por reputação

Para quem: especialistas em automação.

Por quê: não apenas trocar de endereço por timer, mas trocar quando a reputação piora.

Como: integre a verificação periódica do endereço atual ao seu pipeline. Assim que surgir uma marca de abuse (por exemplo, outro assinante no mesmo CGNAT aprontou), acione a rotação. A velocidade de 4–5 ms por endereço permite fazer isso sem atrasos no processo principal.

Erros típicos e como evitá-los

Reunimos erros comuns que vemos na prática.

  • Verificar o endereço só depois do ban. Nesse ponto, a conta já foi perdida. A verificação deve ser pré-lançamento, não post-mortem.
  • Achar que IP móvel é imune. Já discutimos: a marca de abuse é possível até em IP móvel. Verifique também os pools móveis.
  • Ignorar o nome da fonte. Uma marca no recorte semanal e uma marca recente são níveis diferentes de atualidade. Veja o filename, não apenas a categoria.
  • Buscar só barateza no pool. Economizar em proxy custa caro em recuperação de bans e verba desperdiçada em testes. Calcule o custo total.
  • Não diferenciar categorias de marcas. anonymizers e abuse exigem reações diferentes. A primeira às vezes dá para tolerar; a segunda, quase nunca.

Combinações com outras ferramentas

A verificação de reputação não substitui a higiene geral; ela complementa. Como isso se encaixa:

  • Navegador antidetect + verificação de IP. A impressão digital cobre o nível comportamental e técnico; a verificação de IP cobre o nível de rede. Juntas, elas cobrem os dois estágios em que o antifraude avalia você.
  • Sistema de gerenciamento de perfis + verificação em lote. Atribua endereços aos perfis somente após filtrar por reputação. A verificação de 100 endereços por requisição é facilmente integrada a essa etapa.
  • Parser + rotação por reputação. Faça o parser receber apenas endereços limpos do pool, e os que se corromperem vão automaticamente para o descarte.

Comparação de abordagens: proxy barato versus móvel com verificação

Vamos resumir a diferença em um quadro claro, sem citar concorrentes específicos.

Proxy compartilhado ou público

  • Frequentemente está em catálogos de anonymizers (socks_proxy, firehol_proxies).
  • Muitas vezes carrega marcas de abuse e spam, devido ao histórico de uso por qualquer pessoa.
  • Os piores exemplares estão em 32 listas ao mesmo tempo.
  • Mais barato no início, mais caro no final, por causa de bans e captcha.

IP móvel com verificação de reputação

  • Arquiteturalmente ausente dos catálogos de proxies abertos.
  • Está no meio do tráfego real de assinantes via CGNAT.
  • O site não quer bloqueá-lo por inteiro, porque há clientes reais atrás dele.
  • O risco de marca de abuse existe, mas é gerenciado com verificação e rotação.

A conclusão não é que um é “melhor”, mas que a abordagem móvel tem probabilidades diferentes e ferramentas de controle. É a diferença entre esperança e um processo gerenciável.

FAQ

Preciso me registrar para verificar um endereço?

Para a verificação básica via API, não é necessário registro nem chave. Basta enviar a requisição POST e ler a resposta.

Quantos endereços posso verificar em uma requisição?

Até 100 endereços por requisição. A velocidade de processamento é de 4–5 ms por endereço, e todo o pool é verificado em frações de segundo.

Com que frequência as listas são atualizadas?

Diariamente. A confiabilidade da sincronização é de 94,4% de atualizações bem-sucedidas no mês. No total, são 162 fontes e 8 categorias.

O que significa found: true?

O endereço foi encontrado em pelo menos uma das listas. Em seguida, veja o array sources, com categorias e nomes de arquivos, para entender a gravidade do problema.

Marca anonymizers é sentença?

Não. É um sinal de desconfiança elevada: possível captcha e limitações. As marcas abuse e spam são bem mais graves e costumam levar a ban direto.

Proxies móveis podem cair em blocklists?

Nos catálogos de proxies abertos, praticamente não, por arquitetura de redes celulares. Mas, em listas de spam/abuse, um IP móvel pode cair, se algum assinante no mesmo CGNAT abusou. Por isso, verificação e rotação são necessárias também aqui.

Por que o proxy barato sai mais caro no final?

Porque endereços compartilhados são usados por todo mundo durante anos, acumulando marcas de várias categorias. Banco de conta, aquecimento perdido e verba desperdiçada em testes custam mais do que a diferença de preço do proxy.

Como integrar a verificação à automação?

Envie uma requisição em lote na etapa de atribuição de endereços aos perfis e verifique periodicamente os endereços ativos. Ao surgir marca de abuse, acione a rotação.

O que é mais importante — impressão digital ou reputação do IP?

Ambas são importantes, mas são verificadas em etapas diferentes. A reputação do IP é avaliada antes, antes de o navegador renderizar. Uma impressão digital perfeita não salva se o endereço já está em listas negras.

Quantos endereços a base cobre?

7,11 milhões de IPs individuais, mais 356 mil sub-redes, o que resulta em mais de 2,1 bilhões de endereços cobertos. A maior categoria é anonymizers, com 4,88 milhões de endereços.

Conclusões: por onde começar

Vamos juntar tudo. O ban de uma conta nem sempre é sobre impressão digital. Muitas vezes, o motivo está na reputação do próprio IP, conhecida pelo site antes da primeira requisição. Os feeds públicos catalogam proxies abertos e anonymizers, e o histórico de abusos adiciona marcas de abuse e spam aos endereços. Proxies baratos acumulam os dois tipos de rótulos, e os piores aparecem em 32 listas ao mesmo tempo.

IPs móveis são diferentes: por trás do endereço CGNAT da operadora estão centenas de assinantes reais, esse endereço não entra em catálogos de proxies abertos, e o site não quer bloqueá-lo por inteiro. Mas o IP móvel também não é armadura — a marca de abuse é possível aqui. Por isso, a prática de trabalho é a mesma, independentemente do tipo de proxy: verificar a reputação antes do uso e rotacionar quando ela piora.

Para quem isso é especialmente relevante: profissionais de multiacting, scraping, automação e mídia paga — todos que trabalham com pools de endereços e pagam por cada conta queimada em tempo e dinheiro.

Como começar agora:

  1. Pegue os endereços que usa e submeta-os à verificação via API — sem registro ou chave. Um endereço com curl ou um lote de até 100 endereços por requisição.
  2. Filtre os endereços com marcas de abuse e spam. Avalie quantos do seu pool são, de fato, problemáticos.
  3. Estruture o processo para que apenas endereços verificados entrem em uso, e os que se corromperem vão para a rotação.

Se você não quer montar uma combinação de ferramentas separadas, a verificação de reputação já está integrada ao mobileproxy.space. Você obtém endereços móveis e a possibilidade de consultá-los nas listas dentro do mesmo fluxo de trabalho — como uma solução pronta para o problema com o qual começamos: saber do problema antes do ban, não depois.