Reputação de IP e Pontuação de Fraude no IPQualityScore: Guia Técnico 2026

Se você opera sistemas anti-fraude ou gerencia infraestrutura de scraping, já enfrentou o cenário: uma requisição legítima é bloqueada porque o IP de saída tem uma pontuação de fraude alta, ou um atacante passa despercebido porque o IP parece “residencial” o suficiente. Entender como funciona a reputação de IP e a pontuação de fraude IPQualityScore é essencial para resolver ambos os problemas — seja para proteger seu endpoint de checkout ou para garantir que sua automação autorizada não seja sinalizada.

Neste guia técnico, vamos dissecar como serviços como o IPQualityScore (IPQS) constroem sua pontuação de 0–100, quais sinais específicos eles avaliam, e por que proxies residenciais genuínos passam onde IPs de datacenter falham sistematicamente.

Como funciona a reputação de IP e a pontuação de fraude IPQualityScore

O IPQS e serviços similares atribuem uma pontuação de fraude de 0 a 100 para cada endereço IP consultado. Quanto mais alto, maior a probabilidade de o IP ser malicioso ou pertencer a infraestrutura de automação. Mas essa pontuação não é mágica — ela é construída a partir de múltiplas camadas de evidência.

Honeypots e armadilhas

Provedores de detecção de fraude mantêm redes de honeypots — sites falsos, formulários de login simulados e endpoints de API deliberadamente expostos — que atraem bots e scrapers. Quando um IP interage com esses honeypots, ele é marcado como “abuso recente” e sua pontuação de fraude sobe. O IPQS mantém uma base de dados desses IPs que é atualizada continuamente, com janelas de decaimento que reduzem a severidade da marcação ao longo de 30–90 dias se o IP não apresentar mais comportamento suspeito.

Classificação de ASN e faixa

Cada bloco de IPs pertence a um Autonomous System Number (ASN). O IPQS classifica ASNs em categorias: ISP residencial (ex: AS7922 Comcast, AS3320 Deutsche Telekom), hosting/datacenter (ex: AS14061 DigitalOcean, AS16509 Amazon AWS), e mobile (ex: AS22394 Cellco Partnership/Verizon). Um IP originado de um ASN de hosting recebe automaticamente uma pontuação base mais alta — tipicamente 50–70 pontos antes mesmo de outras verificações — porque a maioria do tráfego legítimo de consumidores não vem de datacenters.

Blacklists e feeds de ameaças

O IPQS agrega dados de dezenas de blacklists públicas e privadas, incluindo Spamhaus, AbuseIPDB e feeds próprios. Se um IP aparece em qualquer blacklist relevante, sua pontuação de fraude recebe um incremento significativo. A presença em múltiplas listas pode empurrar a pontuação para 85+ instantaneamente.

Machine learning e padrões de abuso escalável

Além das regras determinísticas, o IPQS aplica modelos de machine learning treinados em bilhões de requisições para identificar padrões de “abuso escalável” — comportamentos que indicam automação em massa: alta taxa de requisições por segundo a partir de um mesmo IP, varredura de portas, tentativas de login sequenciais, e padrões de navegação não-humanos (tempo entre cliques, profundidade de scroll, divergência entre User-Agent declarado e fingerprint do navegador).

Verificações forenses em tempo real

Quando uma requisição chega, o IPQS executa verificações em tempo real:

• Proxy/VPN/Tor: detecta assinaturas de proxies abertos, serviços VPN comerciais e nós de saída da rede Tor.
• Portas abertas: verifica se portas comuns de proxy (3128, 8080, 1080, 8888) estão expostas no IP.
• rDNS (reverse DNS): confere se o registro PTR do IP corresponde a um hostname residencial (ex: cpe-72-178-xx-xx.res.rr.com) ou de datacenter (ex: ec2-54-210-xx-xx.compute-1.amazonaws.com).
• Geolocalização: cruza a localização declarada do IP com dados de GeoIP e verifica consistência com o fuso horário do navegador.

Sinais de detecção de proxy que você precisa conhecer

Para quem constrói sistemas anti-fraude ou avalia a qualidade de proxies, é crucial entender os sinais específicos que o IPQS e sistemas similares utilizam. Vamos detalhar cada um.

Tipo de ASN: hosting vs ISP

Este é o sinal mais determinante. O IPQS consulta a base de dados ASN e classifica a conexão. ASNs de ISPs tradicionais (residenciais) recebem um tratamento benigno, enquanto ASNs de provedores de hosting (DigitalOcean, Hetzner, OVH, AWS, Google Cloud) são marcados como “datacenter” — um sinal vermelho quase automático. Isso é visível no campo connection_type da API do IPQS, que retorna “Residential”, “Corporate” ou “Datacenter”.

Portas abertas e varredura de serviços

O IPQS verifica se portas associadas a proxies, VPNs ou serviços de tunelamento estão abertas no IP consultado. Um IP residencial genuíno tipicamente não tem portas 1080 (SOCKS), 3128 (Squid), 8080 (HTTP proxy) ou 1194 (OpenVPN) expostas. A presença dessas portas eleva a pontuação de fraude de IP em 15–30 pontos.

rDNS e consistência de hostname

O registro PTR (reverse DNS) é um sinal forte. IPs de datacenter frequentemente têm hostnames que contêm o nome do provedor de cloud (ex: ip-10-0-0-1.ec2.internal). IPs residenciais geralmente têm hostnames atribuídos pelo ISP que seguem padrões como 72-178-xx-xx.res.rr.com ou dsl-xxx-xxx.telecom.net. O IPQS usa essa informação como um dos principais discriminadores na detecção de proxy IPQualityScore.

Inconsistência de geolocalização

Se o IP está registrado em um país, mas o navegador reporta um fuso horário diferente, ou se os dados de GeoIP apontam para uma localidade que não corresponde à localização esperada do usuário, o IPQS incrementa a pontuação. Esse sinal é particularmente relevante para proxies que roteiam tráfego através de países diferentes daquele onde o usuário real está.

Histórico de abuso recente

O campo recent_abuse na API do IPQS indica se o IP foi reportado por comportamento malicioso nos últimos 30 dias. Um IP de datacenter compartilhado pode ter sido usado por múltiplos clientes — e se um deles fez scraping agressivo ou tentativas de fraude, o IP inteiro fica marcado. Isso é um problema fundamental de IPs de datacenter: você herda a reputação de todos que usaram aquele IP antes de você.

Fingerprinting de TLS: JA3 e JA4

Além da reputação do IP em si, sistemas modernos de detecção usam fingerprints de TLS para identificar clientes automatizados. O JA3 fingerprint é um hash das cipher suites e extensões TLS enviadas no ClientHello. Bibliotecas como requests ou curl produzem fingerprints JA3 distintos dos de navegadores reais (Chrome, Firefox). O JA4, evolução mais recente, adiciona o ALPN e versões de protocolo ao hash.

Um IP residencial com uma pontuação de fraude baixa ainda pode ser sinalizado se o servidor detectar um JA3 que não corresponde a nenhum navegador conhecido. É por isso que ferramentas como curl-impersonate ou bibliotecas como cycletls existem — elas reproduzem o ClientHello de navegadores específicos para passar por essa camada de detecção.

Canvas fingerprinting e sinais JavaScript

Em uma camada mais profunda, sites podem coletar fingerprints de canvas (renderização de texto e formas em elemento <canvas>), WebGL, fontes instaladas e propriedades do navegador via JavaScript. Um proxy residencial não ajuda — e nem deveria — com esses sinais. Eles são independentes do IP. Mas a combinação de “IP residencial limpo + fingerprint de navegador legítimo” é o que faz uma requisição passar por todos os filtros.

Por que os limiares importam: bloquear score ≥ 90

O IPQS recomenda que seus clientes bloqueiem ou desafiem IPs com pontuação de fraude ≥ 90, e apliquem desafios adicionais (CAPTCHA, verificação por email, 2FA) para pontuações entre 75 e 89. Mas a configuração do limiar depende do contexto:

Esses limiares são calibrados porque falsos positivos têm custos diferentes em cada contexto. Bloquear um usuário legítimo no checkout custa uma venda imediata; bloquear um bot no signup apenas frustra um atacante. Sites sofisticados implementam lógica condicional: se o IP tem fraud_score ≥ 90 e proxy == true, bloqueiam imediatamente; se fraud_score ≥ 75 mas proxy == false, aplicam um desafio.

Por que proxies residenciais passam onde IPs de datacenter falham

Aqui está o cerne do problema de detecção: um proxy residencial genuíno usa um IP atribuído por um ISP real a um dispositivo físico em uma residência. Esse IP tem:

• ASN de ISP residencial — não de hosting. O IPQS classifica como “Residential”, não “Datacenter”.
• Geolocalização residencial — o GeoIP aponta para uma cidade real, não para um datacenter.
• rDNS residencial — o registro PTR segue o padrão do ISP, não de um provedor de cloud.
• Baixa pontuação de fraude — tipicamente entre 0 e 20, porque o IP não foi usado para abuso em massa.
• Sem portas de proxy expostas — o tráfego sai pela conexão residencial normal.

Compare isso com um IP de datacenter:

É por isso que a detecção de proxy residencial é um problema fundamentalmente diferente da detecção de proxy de datacenter. Não há um sinal único que revele “este IP é um proxy residencial” — porque tecnicamente, o IP é um IP residencial legítimo. O tráfego está sendo roteado através dele, mas o IP em si tem todas as características de uma conexão residencial genuína.

Isso não significa que proxies residenciais sejam indetectáveis. Sistemas sofisticados podem identificar padrões comportamentais: um IP residencial que faz 10.000 requisições por hora a um site de e-commerce é anômalo, independentemente do tipo de ASN. Análise comportamental e rate limiting por IP continuam sendo as defesas mais eficazes contra abuso via proxies residenciais.

Exemplo prático: consultando a API de detecção de proxy do IPQS

Vamos colocar isso em prática. O código abaixo faz duas coisas: (1) obtém o IP de saída de um proxy residencial ProxyHat com geolocalização nos EUA, e (2) consulta a API de detecção de proxy do IPQS para esse IP e para um IP de datacenter, comparando os resultados.

import requests

# --- Configuração ---
IPQS_API_KEY = "sua_api_key_aqui"

# ProxyHat residential proxy - exit US
proxyhat_proxy = {
    "http": "http://user-country-US:pass@gate.proxyhat.com:8080",
    "https": "http://user-country-US:pass@gate.proxyhat.com:8080",
}

def get_exit_ip(proxy_config):
    """Obtém o IP de saída através do proxy configurado."""
    resp = requests.get(
        "https://api.ipify.org?format=json",
        proxies=proxy_config,
        timeout=30
    )
    return resp.json()["ip"]

def check_ip_quality(ip_address):
    """Consulta a API de proxy detection do IPQualityScore."""
    url = f"https://www.ipqualityscore.com/api/json/ip/{IPQS_API_KEY}/{ip_address}"
    params = {
        "strictness": 1,
        "allow_public_access_points": "true",
        "lighter_penalties": "false",
    }
    response = requests.get(url, params=params, timeout=30)
    return response.json()

# Passo 1: Obter IP de saída residencial via ProxyHat
print("Obtendo IP de saída via ProxyHat residential (US)...")
residential_ip = get_exit_ip(proxyhat_proxy)
print(f"IP de saída: {residential_ip}")

# Passo 2: Verificar reputação do IP residencial
print("\n=== ProxyHat Residential IP ===")
res_result = check_ip_quality(residential_ip)
print(f"Fraud Score:     {res_result.get('fraud_score')}")
print(f"Proxy:          {res_result.get('proxy')}")
print(f"VPN:            {res_result.get('vpn')}")
print(f"Tor:            {res_result.get('tor')}")
print(f"Recent Abuse:   {res_result.get('recent_abuse')}")
print(f"ISP:            {res_result.get('ISP')}")
print(f"Connection:     {res_result.get('connection_type')}")
print(f"Country:        {res_result.get('country_code')}")

# Passo 3: Comparar com um IP de datacenter conhecido
datacenter_ip = "104.131.0.1"  # DigitalOcean
print("\n=== Datacenter IP (DigitalOcean) ===")
dc_result = check_ip_quality(datacenter_ip)
print(f"Fraud Score:     {dc_result.get('fraud_score')}")
print(f"Proxy:          {dc_result.get('proxy')}")
print(f"VPN:            {dc_result.get('vpn')}")
print(f"Tor:            {dc_result.get('tor')}")
print(f"Recent Abuse:   {dc_result.get('recent_abuse')}")
print(f"ISP:            {dc_result.get('ISP')}")
print(f"Connection:     {dc_result.get('connection_type')}")
print(f"Country:        {dc_result.get('country_code')}")

# Passo 4: Análise comparativa
print("\n=== Análise ===")
res_score = res_result.get('fraud_score', 100)
dc_score = dc_result.get('fraud_score', 100)
print(f"Residential fraud score: {res_score} (passa se < 75)")
print(f"Datacenter fraud score:   {dc_score} (passa se < 75)")
print(f"Veredicto residential: {'PASS' if res_score < 75 else 'BLOCK'}")
print(f"Veredicto datacenter:   {'PASS' if dc_score < 75 else 'BLOCK'}")

Resultado esperado: o IP residencial do ProxyHat deve ter fraud_score entre 0 e 20, proxy = false, connection_type = “Residential”. O IP de datacenter deve ter fraud_score ≥ 50, connection_type = “Datacenter”.

Você também pode testar com curl usando o SOCKS5 do ProxyHat:

# Obter IP de saída via SOCKS5 ProxyHat
curl --socks5 user-country-US:pass@gate.proxyhat.com:1080 \
  https://api.ipify.org

# Consultar IPQS para o IP obtido
curl "https://www.ipqualityscore.com/api/json/ip/SUA_KEY/IP_OBTIDO?strictness=1"

Para configurar sessões sticky (mesmo IP mantido entre requisições), use o parâmetro session no username:

# Sessão sticky com IP residencial US
proxy_url = "http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080"

Consulte a documentação do ProxyHat para detalhes completos de configuração, e confira os locais disponíveis para geolocalização por país e cidade. Para entender custos, veja os planos do ProxyHat.

Erros comuns e casos extremos

1. Confiar apenas na pontuação de fraude

Um IP com fraud_score = 0 não é garantia de segurança. Um atacante pode usar um proxy residencial recém-adquirido que ainda não foi marcado. Combine a pontuação de IP com sinais comportamentais — velocidade de preenchimento de formulário, padrões de clique, consistência de fuso horário — para uma defesa em profundidade.

2. Ignorar o campo recent_abuse

Um IP residencial pode ter uma pontuação baixa mas recent_abuse = true, indicando que foi reportado recentemente. Esse é um sinal que muitos implementadores ignoram, mas é um dos mais preditivos. Configure seu sistema para desafiar IPs com recent_abuse = true mesmo se a pontuação estiver abaixo do limiar.

3. Usar IPs de datacenter para scraping de sites com proteção anti-bot

Sites protegidos por Cloudflare, Datadome, PerimeterX ou Akamai Bot Manager vão bloquear IPs de datacenter quase instantaneamente. A reputação de IP é a primeira camada de defesa desses sistemas. Se você está fazendo web scraping ou SERP tracking, proxies residenciais não são um luxo — são um requisito.

4. Não rotacionar IPs residenciais

Mesmo proxies residenciais podem ser sinalizados se um único IP fizer muitas requisições. Use rotação por requisição (cada requisição sai por um IP diferente) ou sessões sticky com rotação periódica. O ProxyHat suporta ambos os modos — basta omitir o parâmetro session para rotação por requisição, ou defini-lo para sessões sticky.

5. Esquecer do fingerprinting de TLS

Como mencionado, um IP residencial limpo não ajuda se seu client TLS tem um fingerprint JA3/JA4 de biblioteca automatizada. Use bibliotecas que reproduzem fingerprints de navegadores reais ou ferramentas como Playwright/Puppeteer com stealth plugins quando a detecção for agressiva.

Considerações éticas e legais

Verificar a reputação de IP e a pontuação de fraude do seu próprio IP de saída é legítimo — é prática padrão de segurança e QA. Testar a qualidade dos proxies que você adquire é não apenas legítimo, mas recomendado: você precisa saber se está recebendo o que pagou.

No entanto, usar proxies para cometer fraude de pagamento, evasão de banimentos, ou acessar sistemas sem autorização viola leis como o Computer Fraud and Abuse Act (CFAA) nos EUA e o GDPR na Europa. O uso de proxies para coletar dados pessoais de cidadãos da UE sem base legal pode constituir violação do GDPR, independentemente de o proxy ser residencial ou de datacenter.

Para automação autorizada — scraping de dados públicos, monitoramento de preços, pesquisa de SEO, testes de QA — proxies residenciais são uma ferramenta legítima. Sempre respeite robots.txt, os termos de serviço do site, e implemente rate limiting razoável.

Principais conclusões

• A pontuação de fraude IPQS (0–100) é construída a partir de honeypots, classificação de ASN, blacklists, ML e verificações forenses em tempo real — não é um único sinal.
• O tipo de ASN é o sinal mais determinante: IPs de datacenter (ASNs de hosting) recebem automaticamente pontuações base de 50–70 antes de outras verificações.
• Proxies residenciais passam porque têm ASN de ISP, geolocalização residencial, rDNS consistente e baixo histórico de abuso — exatamente as características que o IPQS procura em um IP legítimo.
• Limiares importam: o IPQS recomenda bloquear score ≥ 90, mas contextos sensíveis (checkout) exigem limiares mais baixos (≥ 70).
• Fingerprinting TLS (JA3/JA4) é uma camada de detecção independente do IP — um IP residencial limpo não ajuda se seu client TLS parece um bot.
• Use proxies residenciais para automação autorizada — scraping de dados públicos, QA, SERP tracking — nunca para fraude ou acesso não autorizado.