Motivos da pontuação de risco: como ler detection_methods campo a campo

Um cliente é bloqueado no checkout e escreve perguntando por quê. "Nosso fornecedor disse 92" encerra a conversa mal. "A sua conexão veio de um servidor de VPN listado com uma porta OpenVPN aberta" é uma resposta que você pode sustentar, reconsiderar ou ajustar. É isso que uma pontuação de fraude explicável oferece: códigos de motivo, não apenas um número.

Esta página é o dicionário dessas respostas. Para saber o que o número em si significa e onde ficam as faixas, comece por o que é uma pontuação de fraude de IP e como lê-la. Abaixo mostramos a aritmética, rastreamos uma resposta real motivo por motivo, tratamos dos cinco motivos que subtraem e listamos cada valor de detection_methods que o nosso código de pontuação pode retornar, com o seu peso e o que o faz disparar.

Os motivos da pontuação de risco se somam: pontos vezes confiança, depois um limite

Na pontuação do GeoIPHub, cada motivo contribui com os seus pontos multiplicados pela sua confiança, e a pontuação é o total arredondado, limitado entre 0 e 100. Não há nenhum modelo oculto por cima. Esta é a etapa de pontuação da nossa API (scoring.service.ts), reduzida à sua aritmética:

Dois detalhes confundem as pessoas. Primeiro, o confidence na resposta não é a probabilidade de fraude. Ele cresce com o número de motivos e o tamanho médio deles, então quatro motivos modestos podem ter mais confiança do que um grande. Uma consulta sem motivos retorna 0,1. Segundo, a ordem de detection_methods é a ordem em que o código os verifica, não o tamanho deles. Não trate a primeira entrada como o motivo principal.

Outros fornecedores expõem os motivos de forma diferente. As respostas do minFraud da MaxMind trazem risk_score_reasons: multiplicadores sobre a pontuação de risco, cada um com códigos como ANONYMOUS_IP, e a MaxMind observa que eles "geralmente só são retornados para transações de risco médio a alto". O Sigma Identity Fraud da Socure combina uma pontuação entre 0,001 e 0,999 com códigos de motivo que "fornecem informações detalhadas para ajudar você a entender os fatores que influenciaram a pontuação de risco de fraude". Os motivos do GeoIPHub são pontos aditivos, e todo motivo que mexeu na pontuação é listado, seja qual for a pontuação.

Verificamos que a aritmética se mantém com dados ao vivo. Estas sete consultas sem chave foram feitas em 29/10/2026 entre 04:43:09 e 04:43:54 UTC, com cerca de sete segundos de intervalo, e cada pontuação e confiança se reconstrói exatamente a partir dos seus motivos:

Rastreando uma resposta real: AhrefsBot com 35, review

O 5.39.1.230 do AhrefsBot teve pontuação 35, review, porque três motivos somaram 63,5 pontos e a correspondência de rastreador verificado tirou 28,5. É o melhor caso didático porque os motivos puxam em direções opostas. Aqui está a resposta recortada da consulta das 04:43:09 UTC (meta.last_classified_at 2026-10-29T04:43:09.547Z), com os valores sem edição:

Cada motivo corresponde a uma linha de aritmética:

Tire a correspondência de rastreador e a soma é 63,5, que arredonda para 64: step up. O arquivo de faixas verificado levou um rastreador real e declarado de um desafio para uma revisão registrada. Não o levou para allow, porque um motivo atenuante é um peso, não uma allowlist. Uma listagem na Spamhaus no mesmo endereço continua contando.

Onde esta resposta está errada

Um dos quatro motivos é uma lacuna nossa. no_ptr_datacenter diz que o endereço não tem DNS reverso, mas dig -x 5.39.1.230 às 04:44 UTC retornou proxy-fr005-cip7.ahrefs.net. O motivo lê os nossos registros PTR armazenados, e esse registro está faltando.

Corrigir a lacuna não reduziria essa pontuação, e o código mostra por quê. O nosso classificador de PTR lê qualquer hostname que contenha "proxy" como um padrão de proxy. Então, com o registro armazenado, no_ptr_datacenter (+5) seria substituído por rdns_proxy (+14), e a pontuação subiria para pelo menos 44. Continua sendo review, mas por causa de um hostname que a Ahrefs escolheu para a saída do seu rastreador, não por um anonimizador. Registramos as duas coisas. Leia no_ptr_datacenter e os motivos rdns_* como evidências fracas, que é o que os pesos deles já dizem.

Motivos atenuantes: cinco podem subtrair, e param em zero

Os motivos atenuantes têm pontos negativos, então reduzem a soma, mas a pontuação nunca cai abaixo de 0. A configuração de pontuação do GeoIPHub tem seis deles, e cinco podem disparar hoje:

O desconto de rastreador verificado aparece na consulta do Googlebot. datacenter_ip somou 10, verified_crawler tirou 28,5 e a API retornou 0. O saldo de menos 18,5 é descartado. Ele não vira crédito contra um motivo posterior, e esse é o comportamento certo: uma faixa verificada não deveria conseguir esconder uma listagem de botnet. Os 19 arquivos de faixas por trás de verified_crawler estão listados, com as suas datas e um gerador de allowlist, na nossa lista de IPs de rastreadores verificados; como verificar o Googlebot por IP trata dos arquivos do Google em detalhe.

Não podemos mostrar o desconto residencial em um endereço ao vivo, porque publicar a consulta de uma conexão doméstica identificaria uma família. Então aqui está o caminho do código em texto. Os motivos residenciais dependem do DNS reverso: o nosso código só considera uma linha residencial quando o hostname PTR dela corresponde a um padrão doméstico como dsl, pool ou dynamic. Quando isso acontece, a menos que a linha também esteja sinalizada como móvel ou CGNAT, residential_isp (-17) e rdns_residential (-16) disparam juntos, somando menos 33. Uma linha móvel ou de CGNAT recebe mobile_carrier (-12) no lugar de residential_isp, então esse par soma menos 28. Uma linha doméstica cujo ISP não publica DNS reverso, ou nomeia os hosts em um padrão que não reconhecemos, não recebe nenhum dos descontos. Sem mais nada contra ela, simplesmente tem pontuação 0. É a mesma pontuação, então a lacuna só importa quando outros motivos disparam.

Os descontos também se invertem. Se uma linha residencial tem evidência de proxy, Tor ou protocolo de VPN (uma marcação de IPsec sozinha não conta), residential_isp é substituído por residential_with_threat (+21,25). Uma linha móvel faz o mesmo com mobile_with_threat (+16). Um desconto por parecer uma casa é retirado no momento em que a casa começa a retransmitir tráfego.

Dois limites ficam ao lado dos descontos. Um endereço de relay é limitado a 60, então uma saída do iCloud Private Relay nunca chega a block; explicamos como detectar o tráfego do Private Relay e do WARP e por que deixá-lo passar. Um endereço que a nossa etapa de CGNAT sinaliza é limitado a 50, a menos que tenha evidência própria de VPN, proxy, Tor, protocolo de VPN, botnet ou abuso.

Cada valor de detection_methods, campo a campo

O código de pontuação do GeoIPHub pode nomear 41 motivos, e 36 deles podem aparecer em uma resposta hoje. As tabelas abaixo listam todos os 36 com os seus pontos, confiança e contribuição, agrupados pela pergunta que cada um responde.

O endereço é um anonimizador? Estes vêm da lista de saídas do Tor Project, das listas de servidores publicadas pelos provedores, das nossas próprias sondagens de protocolo e de uma lista de proxies de terceiros. As sondagens cobrem SOCKS5, SOCKS4, HTTP CONNECT, HTTP forward, OpenVPN, IKE (v1 e v2), PPTP e L2TP. Não há sondagem de WireGuard.

O endereço se comportou mal? Estes vêm de três zonas de DNSBL e dos nossos feeds de abuso e de botnets.

É infraestrutura de servidores? Hospedagem significa um dos 853 ASNs de hospedagem curados, uma faixa dos 10 provedores de nuvem que carregamos ou uma faixa anycast. Só um dos três motivos datacenter_* pode disparar, do mais forte para o mais fraco.

O que o DNS reverso dele diz? Estes leem o hostname PTR armazenado com padrões simples, e é por isso que cada um tem peso leve.

Que tipo de linha é, e é um rastreador conhecido? Os motivos de tipo de rede são sempre um de um par: o desconto sem evidência de anonimizador ou a penalidade com ela.

Cinco motivos que o código conhece, mas nunca retorna

Cinco nomes existem no código de pontuação do GeoIPHub, mas não podem aparecer em uma resposta hoje, então não crie regras que esperem por eles:

• spoofed_crawler (+42,75). Nada no nosso pipeline o define, e uma consulta só vê um IP, nunca um User-Agent. A comparação entre o nome de bot alegado e threat.crawler acontece no seu código.
• honeypot_hit (+33,25). A contagem de honeypot é um placeholder que é sempre 0.
• known_vpn_asn (+22,5). O nosso código só rotula uma rede como VPN quando o endereço já é uma VPN, então known_vpn_server sempre vence.
• rdns_cgnat (-10,5). O nosso classificador de hostnames não tem padrão de CGNAT.
• shadowsocks_suspected (+10). Não temos sondagem de Shadowsocks, e nenhuma lista de provedores que carregamos marca Shadowsocks.

O arquivo de configuração também guarda mais 11 pesos que o caminho de consulta nunca lê, então esses nomes também nunca chegam a uma resposta. Preferimos listar um motivo inativo a deixar você descobri-lo esperando.

Escreva regras com base nos motivos, não no número bruto

A razão prática para aprender esses nomes é que regras escritas com base nos motivos sobrevivem às nossas lacunas de dados, e regras escritas com base no total não. Os nossos limites de bloqueio para login, cadastro e checkout definem as faixas; dentro delas, algumas regras no nível dos motivos fazem a maior parte do trabalho:

• Trate tor_exit, socks5_open, http_proxy_open e botnet_c2 como fortes por si sós: cada um soma 33 ou mais e vem de uma lista ou da nossa própria sondagem.
• Não aja com base apenas em no_ptr_datacenter, fcrdns_mismatch ou em qualquer motivo rdns_*. Eles valem de 2 a 24 pontos e leem hostnames armazenados que podem estar faltando ou desatualizados.
• Leia verified_crawler junto com threat.crawler.verified e um operador que corresponda ao bot que o User-Agent alega, nunca threat.crawler.name. Um rastreador verificado em uma lista de spam, como o AhrefsBot em 29 de outubro de 2026, pertence à sua allowlist de rastreamento, não ao seu checkout.
• Trate wireguard_open como evidência de lista, não como resultado de sondagem. Significa que a lista publicada pelo provedor diz que o servidor roda WireGuard.
• Registre o array detection_methods completo em cada decisão. É a trilha de auditoria que um agente de suporte ou um revisor de chargeback vai pedir.

Veja como isso fica em código, usando apenas campos reais:

Os motivos também dizem de onde vem a evidência, o que importa quando um cliente a contesta. known_vpn_server com vpn_confidence 95 significa a própria lista do provedor; explicamos como nomeamos o provedor de VPN por trás de um IP e o que cada valor de confiança diz. Do lado das sondagens, como funciona a detecção de VPN e proxy mostra de onde vêm os motivos de anonimizador mais pesados, e a lista completa de campos de dados de IP documenta o restante da resposta.

Some uma pontuação você mesmo

Cole qualquer endereço no verificador gratuito de pontuação de fraude de IP do GeoIPHub, copie os motivos e reconstrua o número a partir das tabelas acima. Se a sua soma e a nossa pontuação discordarem, um de nós tem um bug, e gostaríamos de saber qual.

Perguntas frequentes

O que scoring.detection_methods contém?

O nome de cada motivo que alterou a pontuação, na ordem em que o código de pontuação do GeoIPHub os verifica, não por tamanho. Cada nome tem pontos fixos e uma confiança na nossa configuração de pontuação, e a pontuação é a soma de pontos vezes confiança, arredondada e mantida entre 0 e 100. O código do GeoIPHub pode nomear 41 motivos; 36 podem aparecer em uma resposta hoje.

Por que um rastreador verificado ainda recebe uma pontuação de revisão?

Porque, na pontuação do GeoIPHub, verified_crawler é um peso, não uma allowlist. Ele subtrai 28,5 pontos (menos 30 com confiança de 0,95). O AhrefsBot em 5.39.1.230 também tinha uma listagem na Spamhaus em 29/10/2026, então os motivos de spam e de blocklist superaram o desconto: 35, review, abaixo dos 64 (step up) que teria sem a correspondência de rastreador.

Uma pontuação pode ficar abaixo de zero?

A soma ponderada pode, a pontuação não. O Googlebot em 66.249.66.1 somou menos 18,5 em 29/10/2026 (datacenter_ip mais verified_crawler) e a API do GeoIPHub retornou 0. O saldo negativo não é transferido como crédito para mais nada.

wireguard_open significa que o GeoIPHub completou um handshake de WireGuard?

Não. O GeoIPHub não tem sondagem de WireGuard. wireguard_open significa que a própria lista de servidores publicada pelo provedor de VPN marca aquele servidor como WireGuard. As nossas sondagens cobrem SOCKS5, SOCKS4, HTTP CONNECT, HTTP forward, OpenVPN, IKE (v1 e v2), PPTP e L2TP, então openvpn_open, pptp_open, l2tp_open, socks5_open e http_proxy_open são resultados de sondagem.

Por que vejo no_ptr_datacenter em um endereço que tem DNS reverso?

O motivo lê os registros de DNS reverso armazenados pelo GeoIPHub, não uma consulta ao vivo, e esses registros têm lacunas. Em 29/10/2026 ele disparou para o AhrefsBot 5.39.1.230 e para a saída Tor 185.220.101.1, enquanto dig -x resolveu os dois. Ele vale 5 pontos, então escreva regras com base nos motivos em que você confia, não na contagem bruta.