Detectar VPN e proxy no cadastro: o que o IP entrega e o que ele inventa

Sinal de IP ajuda a pontuar risco e é péssimo para decidir sozinho. Três medições reais em que o classificador errou, e por que a nossa resposta não tem campo de veredito.

A ideia é sedutora e por isso se espalha: pegue o IP de quem está se cadastrando, pergunte a uma API se é VPN, e recuse quem for. Uma linha de código, fraude resolvida.

O problema é que essa linha de código barra cliente legítimo com frequência desconfortável — e quem recebe a reclamação é você, não o fornecedor do dado. Este texto mostra três medições em que o classificador errou, e o que fazer com o sinal em vez de ligá-lo direto na porta.

O 8.8.8.8 é uma VPN — segundo o classificador

O 8.8.8.8 é o DNS público do Google. Não é VPN, não é proxy, não é anonimizador: é provavelmente o endereço IP mais conhecido da internet.

Consultado, ele voltou is_vpn: true, com confiança 60.

E o detalhe que fecha o caso: horas antes, no mesmo dia, o mesmo endereço tinha voltado classificado como serviço de rede / DNS público, com confiança 95. Não é que a base esteja "errada" de forma estável — é que a classificação de um mesmo endereço mudou de categoria e de confiança ao longo do dia.

Se a sua regra fosse if (is_vpn) recusar, o resultado dependeria da hora em que o cliente clicou em cadastrar.

A infraestrutura do GitHub é "atividade maliciosa"

Segunda medição, e essa é mais sutil. O 185.199.108.153 é infraestrutura do GitHub Pages — onde milhões de sites estáticos são servidos.

Ele volta com a flag de atividade maliciosa ligada. E aqui está o detalhe que importa mais que a flag: a confiança era 40 no bloco de segurança e 0 no bloco de anonimato.

Quem lê só o topo da resposta vê "malicioso" e para por aí. Quem lê a confiança descobre que o sinal é fraco. E quem lê o dono do endereço descobre que é uma plataforma de hospedagem enorme, onde um vizinho barulhento contamina a reputação de um bloco inteiro.

Foi por causa deste caso que corrigimos a nossa própria resposta: ela lia sempre a confiança do bloco de anonimato, então esse IP saía como is_malicious: true com confidence: 0 — um sinal sério parecendo sem lastro nenhum. Hoje cada bloco carrega a própria confiança e a própria data.

Datacenter não é fraudador

Terceira: faixas de Google Cloud e DigitalOcean voltam rotuladas como VPN.

Tecnicamente não é absurdo — muita VPN roda em nuvem. Mas a conclusão que o integrador tira é outra: ele lê "VPN" e pensa "alguém escondendo quem é". Quando o que está ali pode ser o backend de um cliente seu, um serviço de monitoramento, ou um app corporativo saindo pela nuvem da empresa.

Por que a nossa resposta NÃO tem um campo de veredito

Esta é uma decisão de produto, e ela custa vendas: a nossa consulta de risco de IP não devolve bloquear, fraude nem verdict.

Não é esquecimento. Um booleano de topo é exatamente o campo que alguém liga na regra de negação — e, com as três medições acima, seria um campo que recusa o Google, o GitHub e metade da nuvem. O falso positivo do classificador viraria cliente legítimo barrado, com a reclamação chegando em nós.

Por isso o bloco se chama signals, e três coisas viajam sempre junto:

campo	para que serve
confidence	separa "tenho certeza" de "chutei" — e o 8.8.8.8 mostrou que isso varia no mesmo dia
last_seen	um IP marcado há dois anos não diz o mesmo que um marcado ontem
network (ASN + organização)	"is_vpn" ao lado de "AS15169 / Google LLC" se lê como datacenter, não como fraudador

É o contexto que transforma um rótulo numa decisão. Sem ele, o rótulo sozinho é um palpite com cara de resposta.

Como usar o sinal sem quebrar o cadastro

O padrão que funciona é tratar IP como peso, nunca como porta:

1. Componha. IP anônimo + e-mail descartável + dispositivo novo + valor alto é um caso. IP anônimo sozinho não é nada — VPN corporativa é rotina em empresa, e muita gente usa VPN por hábito de privacidade.
2. Escalone em vez de recusar. Sinal forte pede verificação adicional (um OTP, um documento), não porta fechada. Recusar é irreversível do ponto de vista da conversão: a pessoa não volta.
3. Leia a confiança. Abaixo de um patamar, o sinal é ruído. Escolha o patamar olhando os seus dados, não o padrão do fornecedor.
4. Olhe o ASN antes de concluir. Organização conhecida muda a leitura por completo.
5. Registre o que decidiu. Quando um cliente reclamar que não conseguiu se cadastrar, a pergunta vai ser "por quê" — e "a API disse VPN" não é resposta.

Quando o IP é realmente útil

Nada disso significa que o sinal não vale. Ele é ótimo em três situações concretas:

• Tor. Aqui o sinal é praticamente binário e a leitura é direta.
• Contradição geográfica. Cadastro com documento brasileiro saindo de um IP de outro continente é uma pergunta legítima a fazer — não uma recusa.
• Concentração. Vinte cadastros do mesmo bloco em dez minutos diz muito mais que qualquer flag num cadastro isolado.

O resumo

O dado de IP é de terceiro, muda ao longo do dia e classifica infraestrutura conhecida como ameaça. Isso não o torna inútil — torna-o um entre vários sinais, com peso proporcional à confiança que ele próprio declara.

A regra prática cabe numa frase: se uma única API pode barrar um cliente seu sozinha, o problema não é a API — é a arquitetura da decisão.