Como Funcionam a Reputação de IP e a Pontuação de Fraude (IPQualityScore) em 2026

A reputação de IP e a pontuação de fraude (IPQualityScore) são o filtro invisível que decide se o seu tráfego automatizado chega ao destino ou é silenciosamente bloqueado. Se você faz scraping, automação de login ou testes de segurança, entender como um score de fraude de 0 a 100 é calculado — e por que um proxy residencial passa onde um IP de datacenter falha — é a diferença entre uma pipeline estável e dias de debugging 403s.

Como a reputação de IP e a pontuação de fraude (IPQualityScore) funcionam

O IPQualityScore (IPQS) é um dos provedores de detecção de fraude mais utilizados na web, integrado em gateways de pagamento, formulários de registro e plataformas de e-commerce. O serviço recebe um endereço IP e retorna um fraud score de 0 a 100, onde valores mais altos indicam maior probabilidade de atividade maliciosa. Mas esse número não é mágica — é a soma ponderada de dezenas de sinais.

Os blocos de construção do fraud score

O IPQS combina várias categorias de dados para chegar ao score final:

• Honeypots e armadilhas: endereços IP conhecidos por terem atacado honeypots operados pelo IPQS e parceiros. Se um IP foi flagrado tentando explorar uma isca, seu score sobe drasticamente.
• Classificação de ASN e range: o IP é mapeado para seu Autonomous System Number (ASN). ASNs de hosting (AS14618 Amazon, AS16509 AWS, AS15169 Google) recebem penalidades. ASNs de ISPs residenciais (AS7922 Comcast, AS3320 Deutsche Telekom) recebem bônus de confiança.
• Listas negras (blacklists): cruzamento com dezenas de listas públicas e privadas de IPs maliciosos, incluindo Spamhaus, SORBS e feeds proprietários.
• Machine learning: modelos treinados sobre bilhões de eventos de tráfego que correlacionam padrões comportamentais com fraudes confirmadas.
• Verificações forenses em tempo real: detecção ativa de proxy/VPN/Tor, checagem de portas abertas, rDNS, e geolocalização.

O resultado é um número único que codifica tudo: histórico de abuso, tipo de conexão, probabilidade de ser um proxy e potencial de abuso escalável. Um IP de datacenter que nunca foi usado para fraude ainda pode receber um score de 75+ simplesmente porque o ASN é classificado como hosting.

Padrões de 'abuso escalável'

O IPQS e serviços similares procuram especificamente por abuso escalável — padrões que indicam que o IP faz parte de uma operação automatizada em massa. Isso inclui:

• Volumes anômalos de requisições em curtos intervalos (ex: 1.500 requisições/segundo de um único IP).
• Tentativas de login com credenciais vazadas (credential stuffing).
• Cadastros em massa com e-mails descartáveis.
• Comportamento de navegação não-humano detectado via análise de eventos JS.

Esses padrões alimentam o modelo de ML que ajusta o score dinamicamente. Um IP limpo pode tornar-se suspeito em horas se apresentar comportamento de bot.

Sinais de detecção de proxy: o que os sistemas vêem

Para entender por que alguns proxies passam e outros falham, precisamos olhar para os sinais específicos que o IPQS e sistemas equivalentes avaliam. A detecção de proxy IPQualityScore não é uma única verificação — é um conjunto de heurísticas:

1. Tipo de ASN (hosting vs ISP)

Este é o sinal mais pesado. O IPQS mantém um banco de dados que classifica cada ASN como residential, mobile, hosting/datacenter ou business. IPs de datacenter são penalizados pesadamente, independentemente do histórico. É a razão número um pela qual proxies de datacenter falham em verificações de fraude.

2. Portas abertas

Verificações ativas escaneiam portas comuns de proxy (3128, 8080, 1080, 8888). Se o IP expõe um servidor SOCKS ou HTTP proxy aberto, o score dispara. Proxies residenciais autenticados não expõem portas públicas — o tráfego sai pela porta 443 do navegador do usuário, indistinguível de tráfego normal.

3. Reverse DNS (rDNS)

O registro PTR do IP é verificado. Um rDNS como ec2-54-213-92-1.us-west-2.compute.amazonaws.com é um sinal imediato de datacenter. Um rDNS como cpe-72-178-12-34.res.rr.com indica ISP residencial. O IPQS usa o rDNS tanto para classificação de ASN quanto para detecção de mismatch de geolocalização.

4. Mismatch de geolocalização

Se o registro de geolocalização do IP (MaxMind, IP2Location) diz Brasil, mas o fuso horário do navegador diz UTC+0, ou o idioma HTTP Accept-Language é ru-RU, o score aumenta. Esse é um sinal clássico de proxy mal configurado.

5. Tipo de conexão

O IPQS classifica a conexão como residential, mobile, corporate ou datacenter. Esta classificação é derivada do ASN, do rDNS e de dados de WHOIS. É um dos fatores de maior peso no score final.

6. Histórico de abuso recente

Um IP que foi flagrado em qualquer lista negra nos últimos 30 dias recebe um bônus de penalidade, mesmo que já tenha sido removido da lista. O IPQS mantém um histórico de abuso que decai com o tempo, mas nunca zera completamente.

7. Sinais de TLS e fingerprinting de navegador

Embora o IPQS se concentre no IP, plataformas modernas combinam a pontuação de IP com fingerprints do cliente. O JA3/JA4 fingerprint — que codifica a ordem de cipher suites TLS, extensões e curvas elípticas — pode identificar um cliente Python requests versus um Chrome real. Por exemplo, o JA3 hash do Python 3.12 com urllib3 é cd08e31494f9531f560d64c695473da9, enquanto o Chrome 120 no Windows produz um hash completamente diferente. Se o IP é residencial mas o JA3 indica uma biblioteca HTTP, o sistema sabe que há um proxy na ponta.

Além do TLS, sinais de JavaScript são verificados:

• navigator.webdriver é true em Selenium/Puppeteer não configurado.
• Canvas fingerprint — bibliotecas de automação headless produzem hashes de canvas diferentes de GPUs reais.
• WebGL renderer — headless Chrome reporta SwiftShader em vez de NVIDIA GeForce RTX 3060.
• screen.width/height — valores padrão como 800x600 indicam ambiente virtualizado.

Para aprofundar esses sinais, a documentação do MDN sobre a API Navigator lista todas as propriedades que scripts anti-bot podem acessar.

Por que thresholds importam e como sites os aplicam

O IPQS recomenda bloquear IPs com fraud score >= 90, mas na prática cada integrador define seu próprio threshold. O padrão típico em 2026:

d>Checkout, criação de conta

Score	Ação típica	Cenário
0–29	Permitir	Tráfego residencial limpo
30–69	Desafio (CAPTCHA, 2FA)	IPs suspeitos mas não confirmadamente fraudulentos
70–89	Revisão manual ou bloqueio em fluxos sensíveis
90–100	Bloqueio automático	Proxy/VPN/Tor confirmado ou histórico de abuso

Esses thresholds são aplicados em pontos críticos da aplicação:

• Login: score alto dispara 2FA obrigatório ou bloqueio direto, protegendo contra credential stuffing.
• Checkout: score >= 70 pode exigir verificação 3DS do cartão ou bloqueio da transação, prevenindo chargebacks.
• Signup: score >= 50 pode exigir verificação de e-mail por SMS ou CAPTCHA, reduzindo criação de contas em massa.

Um IP de datacenter limpo tipicamente recebe 75–85 no IPQS — já no range de bloqueio para muitos integradores. Um IP residencial limpo tipicamente recebe 0–15. Essa diferença de 70+ pontos é o motivo pelo qual proxies residenciais são essenciais para automação que precisa passar por verificações de fraude.

Por que proxies residenciais passam onde datacenter falha

Um proxy residencial genuíno usa um IP atribuído por um ISP a um lar real. Isso significa:

• ASN residencial: o IP está registrado sob um ASN de ISP (ex: AS7922 Comcast, AS3320 Deutsche Telekom), não sob um ASN de hosting.
• rDNS residencial: o PTR aponta para um hostname de ISP, não para um domínio de cloud.
• Geolocalização consistente: o IP está geolocalizado na cidade do ISP, sem mismatch.
• Sem histórico de abuso: IPs residenciais rotativos não acumulam histórico de spam porque cada IP é usado brevemente.
• Baixo fraud score: a combinação dos fatores acima resulta em score 0–15 no IPQS.

Por outro lado, proxies de datacenter falham porque:

• O ASN é classificado como hosting — penalidade automática.
• O rDNS revela o provedor de cloud.
• Range inteiros de IPs de datacenter são pré-classificados como suspeitos.
• O histórico de abuso do range afeta todos os IPs nele.

A tabela abaixo resume a comparação:

Sinal	Residencial (ProxyHat)	Datacenter
ASN	ISP residencial	Hosting/cloud
rDNS	hostname ISP	domínio cloud
Fraud score IPQS	0–15	75–85
Portas de proxy abertas	Não	Possivelmente
Geolocalização	Consistente	Pode ter mismatch
Histórico de abuso	Mínimo	Frequente no range

É importante notar que proxies móveis também passam com scores baixos, pois compartilham a classificação de ASN de operadoras móveis (ex: AS22394 Verizon Wireless). No entanto, proxies móveis são mais caros e têm latência mais alta. Para a maioria dos casos de uso de scraping e automação, proxies residenciais oferecem o melhor equilíbrio entre custo e qualidade de IP.

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

Vamos demonstrar como verificar a qualidade de um IP usando a API do IPQS, comparando um exit residencial do ProxyHat com um IP de datacenter. Este exemplo é para testar a qualidade do seu próprio IP ou validar que sua infraestrutura de proxy está funcionando corretamente.

Pré-requisitos

• Conta no IPQS (plano gratuito permite 5.000 consultas/mês).
• Conta no ProxyHat com proxies residenciais ativos.
• Python 3.10+ com requests instalado.

Código Python

import requests
import json

IPQS_API_KEY = "seu_ipqs_api_key_aqui"
PROXYHAT_USER = "user-country-US"
PROXYHAT_PASS = "sua_senha_aqui"

def check_ip_quality(ip, strictness=1):
    """Consulta a API de proxy detection do IPQS."""
    url = f"https://www.ipqualityscore.com/api/json/ip/{IPQS_API_KEY}/{ip}"
    params = {
        "strictness": strictness,
        "allow_public_access_points": "true",
        "user_agent": "",
        "fastera": "false"
    }
    r = requests.get(url, params=params, timeout=10)
    r.raise_for_status()
    return r.json()

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

# --- ProxyHat residential exit (EUA) ---
residential_proxy = {
    "http": f"http://{PROXYHAT_USER}:{PROXYHAT_PASS}@gate.proxyhat.com:8080",
    "https": f"http://{PROXYHAT_USER}:{PROXYHAT_PASS}@gate.proxyhat.com:8080"
}

residential_ip = get_exit_ip(residential_proxy)
print(f"IP residencial (ProxyHat): {residential_ip}")

res_result = check_ip_quality(residential_ip)
print(json.dumps(res_result, indent=2))

# --- IP de datacenter (conexão direta) ---
dc_ip = requests.get("https://api.ipify.org?format=json", timeout=10).json()["ip"]
print(f"\nIP de datacenter: {dc_ip}")

dc_result = check_ip_quality(dc_ip)
print(json.dumps(dc_result, indent=2))

# --- Resumo comparativo ---
print("\n=== RESUMO ===")
print(f"Residencial: fraud_score={res_result['fraud_score']}, "
      f"proxy={res_result['proxy']}, vpn={res_result['vpn']}, "
      f"connection_type={res_result['connection_type']}")
print(f"Datacenter:  fraud_score={dc_result['fraud_score']}, "
      f"proxy={dc_result['proxy']}, vpn={dc_result['vpn']}, "
      f"connection_type={dc_result['connection_type']}")

O que você deve ver

Para o IP residencial do ProxyHat, o resultado esperado é:

{
  "fraud_score": 0,
  "proxy": false,
  "vpn": false,
  "tor": false,
  "active_vpn": false,
  "active_tor": false,
  "connection_type": "Residential",
  "ISP": "Comcast Cable Communications",
  "ASN": 7922
}

Para o IP de datacenter, o resultado esperado é:

{
  "fraud_score": 82,
  "proxy": true,
  "vpn": false,
  "tor": false,
  "active_vpn": false,
  "active_tor": false,
  "connection_type": "Datacenter",
  "ISP": "Amazon.com",
  "ASN": 14618
}

A diferença é dramática: score 0 vs 82, proxy: false vs proxy: true, connection_type: Residential vs Datacenter. É exatamente essa diferença que determina se o seu scraper recebe a página ou um HTTP 403.

Usando SOCKS5 como alternativa

Se você precisa de SOCKS5 (útil para tráfego UDP ou aplicações que não suportam HTTP proxy), o ProxyHat oferece a porta 1080:

socks5_proxy = {
    "http": f"socks5://{PROXYHAT_USER}:{PROXYHAT_PASS}@gate.proxyhat.com:1080",
    "https": f"socks5://{PROXYHAT_USER}:{PROXYHAT_PASS}@gate.proxyhat.com:1080"
}

Para instalar o suporte a SOCKS5 no Python: pip install requests[socks].

Erros comuns e casos de borda

1. Assumir que todo IP residencial é automaticamente limpo

IPs residenciais podem ser comprometidos. Se um IP residencial foi usado em uma botnet ou teve malware, o IPQS pode atribuir score 30–50. Proxies residenciais de qualidade rotacionam IPs frequentemente justamente para evitar esse problema. Sempre teste seus IPs antes de confiar neles.

2. Ignorar o fingerprint do navegador

Mesmo com um IP residencial perfeito, se o seu JA3 indica Python requests e o navigator.webdriver é true, você será detectado. A solução de IP é necessária mas não suficiente. Use bibliotecas como curl_cffi para forjar JA3 de navegador, ou ferramentas como Playwright com stealth plugins.

3. Não respeitar rate limits

Um IP residencial com score 0 pode rapidamente receber score 80 se você disparar 1.500 requisições/segundo contra um alvo. A reputação de IP é dinâmica. Use rotação de IPs e respeite robots.txt.

4. Mismatch de geolocalização e locale

Se você usa um exit nos EUA (user-country-US) mas envia Accept-Language: pt-BR e um fuso horário de São Paulo, o sistema de fraude detecta a inconsistência. Sempre alinhe geolocalização, idioma e fuso horário.

5. Sessões pegajosas vs rotação por requisição

Para scraping de SERP, rotação por requisição distribui o risco. Para login e sessões autenticadas, use sessões pegajosas (user-session-abc123) para manter o mesmo IP durante toda a sessão — mudar de IP no meio de uma sessão logada é um sinal de fraude clássico.

Configuração no ProxyHat e links úteis

Para começar a usar proxies residenciais do ProxyHat que passam em verificações de fraude como IPQS:

1. Crie sua conta em dashboard.proxyhat.com.
2. Escolha o plano de proxies residenciais adequado na página de preços.
3. Configure o geo-targeting por país ou cidade conforme sua necessidade — veja as localizações disponíveis.
4. Use o formato de username com flags de país: user-country-US para exit nos EUA, user-country-DE-city-berlin para Berlim.
5. Para sessões pegajosas: user-session-abc123 mantém o mesmo IP por até 30 minutos.

Para casos de uso específicos, consulte nossos guias de web scraping e SERP tracking. A documentação técnica completa está em docs.proxyhat.com.

Exemplo com curl

# Requisição HTTP através de proxy residencial ProxyHat
curl -x http://user-country-US:sua_senha@gate.proxyhat.com:8080 \
  https://api.ipify.org

# SOCKS5
curl -x socks5://user-country-US:sua_senha@gate.proxyhat.com:1080 \
  https://api.ipify.org

Considerações éticas e legais

Testar a reputação de IP e a pontuação de fraude é legítimo quando você está:

• Validando a qualidade da sua própria infraestrutura de proxy — garantir que seus IPs residenciais têm scores baixos.
• Realizando pesquisa de segurança autorizada — pentesting com autorização escrita do alvo.
• Automação legítima — scraping de dados públicos, monitoramento de preços, verificação de SERP.

Isto não é legítimo:

• Usar proxies para cometer fraude de pagamento, chargeback ou roubo de identidade.
• Criar contas falsas em massa para manipular rankings ou avaliações.
• Burlar controles de segurança sem autorização do proprietário do sistema.

Sob a GDPR (União Europeia), dados de IP são considerados dados pessoais. Coletar e armazenar IPs de usuários europeus sem base legal pode violar o regulamento. Sob a CFAA (EUA), acessar sistemas de computação sem autorização ou excedendo autorização concedida pode ser crime federal. O fato de você usar um proxy não altera sua responsabilidade legal — o que importa é o que você faz com o acesso.

Sempre respeite robots.txt, os Termos de Serviço da plataforma alvo, e consulte um advogado se não tiver certeza sobre a legalidade da sua operação.

Pontos-chave

A reputação de IP é um sistema dinâmico que combina classificação de ASN, histórico de abuso, verificações forenses em tempo real e machine learning. Proxies residenciais passam porque usam IPs de ISP genuínos com ASN residencial, rDNS consistente e sem histórico de abuso. IPs de datacenter falham porque o ASN de hosting é uma penalidade automática. Teste sempre seus IPs com a API do IPQS antes de confiar neles, e não se esqueça de que o IP é apenas uma camada — o fingerprint do navegador importa tanto quanto.

• O fraud score do IPQS (0–100) combina ASN, honeypots, blacklists, ML e verificações forenses.
• IPs de datacenter recebem score 75–85 automaticamente pelo ASN; IPs residenciais recebem 0–15.
• O threshold de bloqueio recomendado pelo IPQS é >= 90, mas muitos sites bloqueiam a partir de 70.
• Proxies residenciais passam porque têm ASN de ISP, rDNS residencial e geolocalização consistente.
• O fingerprint do navegador (JA3/JA4, canvas, WebGL) é a segunda camada de detecção — não a ignore.
• Teste seus IPs com a API do IPQS antes de usar em produção.
• Use proxies éticamente: valide sua infraestrutura, não cometa fraude.

FAQ

O que é reputação de IP e pontuação de fraude (IPQualityScore)?

É um sistema que atribui uma pontuação de 0 a 100 a cada endereço IP, indicando a probabilidade de atividade fraudulenta. O IPQS combina classificação de ASN, listas negras, honeypots, machine learning e verificações forenses em tempo real (proxy/VPN/Tor, portas abertas, rDNS, geolocalização) para calcular o score. Scores baixos (0–29) indicam tráfego residencial limpo; scores altos (90+) indicam proxy, VPN ou histórico de abuso confirmado.

Por que a reputação de IP e a pontuação de fraude importam para usuários de proxy?

Porque a maioria dos sites de e-commerce, gateways de pagamento e plataformas de login consultam serviços como IPQS em tempo real. Se o seu proxy tem fraud score alto, você é bloqueado, recebe CAPTCHA ou é enviado para verificação 2FA. Proxies de datacenter tipicamente recebem score 75–85 e são bloqueados. Proxies residenciais recebem score 0–15 e passam limpo, permitindo que sua automação funcione sem interrupções.

Qual tipo de proxy funciona melhor para passar por verificações de fraude?

Proxies residenciais são os melhores para passar por verificações de fraude como IPQS. Eles usam IPs atribuídos por ISPs a lares reais, resultando em ASN residencial, rDNS consistente e fraud score baixo (0–15). Proxies móveis também funcionam bem, mas são mais caros. Proxies de datacenter são a pior opção para este cenário — o ASN de hosting gera score 75–85 automaticamente, independentemente do histórico do IP.

Como evitar bloqueios ao implementar automação com proxies?

Use proxies residenciais com rotação de IPs, alinhe geolocalização e locale do navegador, use bibliotecas que forjam JA3/JA4 de navegador real (como curl_cffi ou Playwright com stealth), respeite rate limits (mantenha abaixo de 50 requisições por IP por minuto para alvos sensíveis), use sessões pegajosas para fluxos de login, e teste seus IPs com a API do IPQS antes de deployar em produção. Nunca dispare 1.500 requisições/segundo de um único IP.

O IPQS pode detectar proxies residenciais?

Sim, em alguns casos. Se o IP residencial tiver histórico de abuso, se o rDNS não corresponder à geolocalização, ou se o fingerprint do navegador indicar automação (JA3 de Python, navigator.webdriver=true, canvas fingerprint de headless), o IPQS pode atribuir score elevado mesmo a um IP residencial. A solução de IP é necessária mas não suficiente — o fingerprint do cliente também precisa ser consistente com um navegador real.