Como o reCAPTCHA v3 pontua em 2026: sinais, scores e automação legítima

O reCAPTCHA v3 é diferente de tudo o que veio antes na Google. Não há caixa de seleção, não há imagens de semáforos, não há desafio visual. Em vez disso, ele retorna uma pontuação contínua entre 0.0 e 1.0 para cada ação que o usuário executa — e essa pontuação decide, no servidor, se o tráfego passa. Entender como o reCAPTCHA v3 funciona e por que o recaptcha v3 score colapsa em IPs de datacenter é o primeiro passo para qualquer engenheiro de QA ou pesquisador de anti-bot que precisa de automação confiável em 2026.

Como o reCAPTCHA v3 pontua: o modelo de risco invisível

O reCAPTCHA v3 foi lançado em 2018 com uma premissa radical: nenhuma interação humana visível. O site carrega um script, chama grecaptcha.execute(siteKey, {action: 'login'}) e recebe um token JWT-like que contém uma pontuação de risco. O servidor então envia esse token para https://www.google.com/recaptcha/api/siteverify e recebe de volta um JSON com score, action, hostname, challenge_ts e success.

A pontuação é contínua de 0.0 a 1.0, mas na prática o Google agrupa o tráfego em 11 buckets (0.0, 0.1, 0.2, …, 1.0). Cada bucket representa um nível de risco — 0.0 é “bot quase certo”, 1.0 é “humano quase certo”. A granularidade em décimos existe porque o modelo de machine learning por trás do reCAPTCHA v3 é calibrado para produzir uma distribuição estável, não uma decisão binária.

Os limites típicos adotados por sites em 2026 são:

• Score < 0.3: bloqueio direto ou silencioso. O servidor recusa a requisição, às vezes sem nem retornar um erro visível — apenas um 403 ou um redirecionamento para uma página de “verificação adicional”.
• Score 0.3 – 0.6: zona de desafio. O site pode exigir um reCAPTCHA v2 fallback, um desafio de e-mail/SMS, ou uma verificação adicional antes de liberar a ação.
• Score > 0.6: liberação automática. A maioria dos sites e-commerce, financeiros e de ticketing usa 0.5 ou 0.7 como corte rigoroso.

O ponto crítico: o recaptcha score 0.3 não é um número mágico definido pelo Google — é uma decisão do site baseada na distribuição de tráfego que ele observa. Um site de ticketing pode bloquear qualquer coisa abaixo de 0.7, enquanto um blog pode aceitar até 0.1. O Google apenas fornece a pontuação; o dono do site decide o corte.

Por que esse problema existe: o motor de sinais do Google

O reCAPTCHA v3 não é um único modelo — é uma fusão de dezenas de sinais ponderados por um classificador que o Google treina continuamente com dados de bilhões de requisições. Os principais grupos de sinais em 2026 são:

1. Telemetria de interação no DOM

O script do reCAPTCHA injeta listeners em mousemove, scroll, keydown, click e touchstart. Ele mede:

• Tempo entre eventos (mouse parado por 8 segundos seguido de um clique instantâneo é suspeito).
• Variância na velocidade do mouse — humanos têm tremor e correções; bots têm retas perfeitas.
• Sequência de tabulação e padrões de digitação ( keystroke timing).
• Scroll com aceleração natural vs. scroll programático instantâneo.

2. Grafo de cookies do Google

Se o navegador carrega cookies do Google (NID, SID, __Secure-1PSID), o reCAPTCHA pode correlacionar a sessão com histórico de navegação, logins no YouTube/Gmail, e atividade anterior. Um perfil com meses de histórico legítimo recebe um boost; um perfil novo ou limpo recebe penalidade. É por isso que perfis “frescos” em automação costumam pontuar baixo mesmo com comportamento perfeito.

3. Características do navegador e fingerprints TLS

O Google coleta a User-Agent, a lista de plugins, o navigator.languages, o canvas fingerprint, o WebGL renderer, e — cada vez mais em 2026 — a assinatura TLS da conexão. O JA3/JA4 fingerprint do handshake TLS é um sinal forte: um Chrome real em Windows 11 produz um conjunto de cipher suites e extensões previsível; um requests em Python produz um fingerprint completamente diferente. Bibliotecas como curl-impersonate e Playwright com stealth tentam alinhar o fingerprint TLS, mas o Google atualiza seus modelos quando novos padrões surgem.

4. Reputação do IP

Este é o sinal que mais afeta usuários de proxy. O Google mantém um gráfico de reputação por IP que considera:

• Se o IP pertence a um ASN de datacenter (AWS, DigitalOcean, Hetzner, OVH).
• Volume histórico de tráfego automatizado originado desse IP.
• Se o IP aparece em listas de abuse (Spamhaus, AbuseIPDB).
• Se o IP resolve para um hostname de datacenter (ex.: ec2-x-x.compute.amazonaws.com).

Um IP de datacenter, por melhor que seja o comportamento do navegador, tipicamente recebe um recaptcha v3 score entre 0.1 e 0.3. O Google assume que tráfego de datacenter é, por default, suspeito. É aqui que proxies residenciais entram.

Por que datacenter e IPs marcados colapsam o score

O componente de reputação de IP é multiplicativo, não aditivo. Se o modelo atribui uma probabilidade base de 0.8 ao comportamento do navegador, mas o IP tem reputação de datacenter, a pontuação final pode cair para 0.2 ou 0.3. Não importa o quão humano o mouse se move — o IP sinaliza “infraestrutura de automação”.

Isso é especialmente verdadeiro para:

• IPs de provedores de nuvem conhecidos (AWS, GCP, Azure).
• IPs de VPS baratas (Hetzner, Contabo, OVH).
• IPs que já foram usados em campanhas de scraping massivo e foram reportados.
• IPs de proxies datacenter compartilhados, onde dezenas de clientes reutilizam o mesmo pool.

Por outro lado, IPs residenciais — atribuídos a ISPs como Comcast, AT&T, Vivo, Deutsche Telekom — recebem um boost de reputação porque o Google os associa a usuários domésticos legítimos. Um IP residencial limpo pode elevar o score em 0.2 a 0.4 pontos comparado a um IP de datacenter equivalente. É por isso que qualquer automação que precise passar por reCAPTCHA v3 requer proxies residenciais.

Verificação server-side: siteverify, action e hostname

O fluxo completo do reCAPTCHA v3 tem duas partes. No cliente, o script gera um token via grecaptcha.execute(). No servidor, esse token é enviado para o endpoint siteverify do Google junto com a secret key. A resposta inclui campos críticos que o servidor deve validar:

O erro mais comum em implementações server-side é não validar o action. Se o frontend envia {action: 'login'} mas o servidor não verifica se a resposta do Google retornou action: 'login', um atacante pode reusar um token gerado em uma ação de baixo risco (ex.: page_view) para burlar uma ação de alto risco (ex.: checkout). O Google recomenda explicitamente essa validação na documentação oficial de verificação.

O hostname é igualmente crítico. Se o token foi gerado em evil-clone.com, o hostname na resposta será esse domínio, e o servidor legítimo deve rejeitar. Sem essa checagem, um atacante pode gerar tokens em um site que ele controla (usando a mesma site key, se vazada) e injetá-los no alvo.

Abordagem legítima com ProxyHat: navegador real + proxy residencial

Para automação legítima — QA de acessibilidade, testes autorizados de pentest, pesquisa de SERP com consentimento — o caminho correto não é “burlar” o reCAPTCHA v3, mas sim operar dentro dos limites que o Google considera humano. Isso significa:

1. Usar um navegador real (Chrome, Firefox) via Playwright ou Puppeteer — nunca requests puro.
2. Rotear o tráfego por um proxy residencial limpo, como os da ProxyHat.
3. Mover o mouse, digitar e scrollar com padrões humanos (não instantâneos).
4. Manter sessões sticky por tempo suficiente para acumular telemetria de interação.
5. Respeitar robots.txt e os termos de serviço do alvo.

O ProxyHat oferece proxies residenciais roteados via gate.proxyhat.com com geo-targeting por país e cidade. Para um teste contra um site dos EUA, você usaria um IP residencial americano para maximizar a coerência entre o IP, o fuso horário do navegador e o idioma.

Exemplo em Python com Playwright + ProxyHat

from playwright.sync_api import sync_playwright
import time, random

PROXY = "http://user-country-US:sua_senha@gate.proxyhat.com:8080"

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,
        proxy={"server": PROXY}
    )
    context = browser.new_context(
        viewport={"width": 1920, "height": 1080},
        locale="en-US",
        timezone_id="America/New_York"
    )
    page = context.new_page()
    page.goto("https://exemplo-com-reCAPTCHA.com/login")

    # Movimento de mouse humano: curvas, pausas, tremor
    for _ in range(3):
        page.mouse.move(random.randint(100, 800), random.randint(100, 600))
        time.sleep(random.uniform(0.3, 0.8))

    # Digitação com atraso entre teclas
    page.fill("#username", "qa_tester")
    page.wait_for_timeout(500)
    page.type("#password", "senha_segura", delay=random.randint(80, 150))

    # Scroll natural
    page.mouse.wheel(0, random.randint(50, 200))
    time.sleep(random.uniform(0.5, 1.2))

    # Antes de clicar, esperar o reCAPTCHA carregar e pontuar
    page.wait_for_timeout(2000)
    page.click("#login-button")

    # Verificar resultado
    page.wait_for_timeout(3000)
    print("Score esperado: > 0.5 com IP residencial US")
    browser.close()

Esse exemplo não é um recaptcha v3 bypass — é uma interação legítima que o Google deve pontuar como humana porque é essencialmente humana, apenas assistida. A diferença entre um bot detectável e automação aceitável está nos detalhes: atrasos realistas, movimento de mouse com curvas, e um IP que não grita “datacenter”.

Configurando o proxy corretamente

O formato do usuário ProxyHat permite geo-targeting granular. Para maximizar a coerência:

• user-country-US — IP residencial aleatório nos EUA.
• user-country-US-city-new_york — IP em uma cidade específica (útil para sites que validam geolocalização por IP vs. GPS).
• user-session-abc123 — sessão sticky para manter o mesmo IP entre requisições e acumular reputação.

Exemplo com sessão sticky e cidade:

http://user-country-US-city-new_york-session-qa01:sua_senha@gate.proxyhat.com:8080

Para SOCKS5 (útil quando o navegador suporta apenas SOCKS), use a porta 1080:

socks5://user-country-US:sua_senha@gate.proxyhat.com:1080

Confira os locais disponíveis e o preço para escolher o plano adequado ao volume de testes.

Erros comuns e casos de borda

1. Usar headless puro sem stealth

Chrome headless “puro” (sem flags de stealth) vaza navigator.webdriver = true, não renderiza WebGL corretamente, e tem um fingerprint de canvas diferente do Chrome normal. O reCAPTCHA detecta isso e pontua baixo. Solução: usar Playwright com headless=False em ambientes de CI com display virtual (Xvfb), ou aplicar patches de stealth como playwright-stealth.

2. Reusar tokens

Cada token do reCAPTCHA v3 é válido por 2 minutos e para uma única verificação. Tentar reusar um token em múltiplas requisições retorna success: false com error-codes: [timeout-or-duplicate]. Em automação, gere um novo token por ação.

3. Ignorar o fuso horário e o idioma

Se o IP é dos EUA mas o navegador está em pt-BR com fuso America/Sao_Paulo, o reCAPTCHA pode penalizar a inconsistência. Sempre alinhe locale, timezone_id e o país do proxy.

4. Volume excessivo por IP

Mesmo IPs residenciais têm limite. Se um único IP faz 500 ações/minuto, o Google reclassifica esse IP como suspeito. Distribua o tráfego entre múltiplos IPs residenciais (rotação) e respeite rate limits razoáveis — 1 a 5 ações por minuto por IP é seguro para a maioria dos sites.

5. Não validar action no servidor durante testes

Se você está testando seu próprio site, certifique-se de que sua validação server-side está correta. Um bug comum: o frontend envia action: 'submit_form' mas o backend verifica action == 'login' — isso rejeita tráfego legítimo. Veja a documentação oficial do reCAPTCHA v3 para a referência completa.

Onde isso é apropriado (e onde não é)

Automação que interage com reCAPTCHA v3 é legítima em vários cenários:

• QA de acessibilidade: testar se usuários com leitores de tela conseguem completar fluxos sem serem bloqueados injustamente.
• Pentest autorizado: avaliar se a implementação de reCAPTCHA v3 de um cliente está correta (validação de action, hostname, score threshold).
• Monitoramento de SERP: verificar posicionamento de SEO em escala, respeitando robots.txt e limites de taxa.
• Testes de carga em seu próprio site: simular tráfego real para calibrar thresholds.

Não é legítimo em:

• Criação de contas em massa para fraudes.
• Bypass de limites de ticketing/sneaker drops para revenda.
• Spam de comentários ou reviews.
• Qualquer atividade que viole o Computer Fraud and Abuse Act (CFAA) dos EUA ou o GDPR europeu.

Sob o CFAA, acessar um sistema “sem autorização” ou “excedendo autorização” é crime federal nos EUA. Mesmo se você “apenas” raspou dados públicos, o histórico de casos (ex.: hiQ Labs v. LinkedIn) mostra que a linha é nebulosa. Sob o GDPR, coletar dados pessoais sem base legal pode gerar multas de até 4% do faturamento global. Se você não tem autorização explícita do dono do site, consulte um advogado antes de automatizar.

Comparação: tipos de proxy vs. score esperado no reCAPTCHA v3

Proxies móveis têm a reputação mais alta porque o Google confia em tráfego de redes celulares legítimas — mas são caros. Para a maioria dos casos de QA e pesquisa, residenciais rotativos ou sticky são o ponto ideal custo-benefício. Veja as casos de uso de SERP tracking para mais contexto.

Próximos passos

Se você está implementando automação que precisa passar por reCAPTCHA v3:

1. Comece com um plano residencial da ProxyHat — veja o preço.
2. Configure o navegador com Playwright, alinhando locale, timezone e país do proxy.
3. Implemente movimento de mouse e digitação humanos — não instantâneos.
4. Monitore o score retornado pelo siteverify do Google e ajuste o comportamento.
5. Documente sua autorização legal para cada alvo.

Para detalhes técnicos de configuração, consulte a documentação da ProxyHat.

Principais conclusões

• O reCAPTCHA v3 retorna uma pontuação contínua 0.0–1.0 por ação; sites tipicamente bloqueiam < 0.3, desafiam 0.3–0.6, e liberam > 0.6.
• O score é uma fusão de telemetria de interação, grafo de cookies do Google, fingerprint do navegador (incluindo TLS JA3/JA4) e reputação do IP.
• IPs de datacenter colapsam o score para 0.1–0.3 independentemente do comportamento; proxies residenciais são necessários.
• Validação server-side deve checar action, hostname e challenge_ts — não apenas success e score.
• Automação legítima usa navegador real + proxy residencial + interação humana-like; não é bypass, é conformidade com o modelo de risco.
• Respeite CFAA, GDPR, robots.txt e ToS — sem autorização, não automatize.

Perguntas frequentes

O que é o score do reCAPTCHA v3?

O reCAPTCHA v3 retorna uma pontuação contínua entre 0.0 e 1.0 para cada ação executada via grecaptcha.execute(). O Google agrupa o tráfego em 11 buckets (0.0 a 1.0 em décimos). Sites usam essa pontuação para decidir se bloqueiam (< 0.3), desafiam (0.3–0.6) ou liberam (> 0.6) o tráfego. A pontuação é gerada por um modelo de machine learning que fusiona telemetria de interação, reputação de IP, fingerprint do navegador e o grafo de cookies do Google.

Por que o score do reCAPTCHA v3 importa para usuários de proxy?

O componente de reputação de IP é multiplicativo. Um IP de datacenter, mesmo com comportamento perfeito de navegador, tipicamente recebe 0.1–0.3 porque o Google associa ASNs de nuvem a automação. Proxies residenciais (Comcast, AT&T, Vivo) recebem um boost de reputação que pode elevar o score em 0.2–0.4 pontos. Sem proxy residencial, a maioria dos sites bloqueia ou desafia a automação.

Qual tipo de proxy funciona melhor para reCAPTCHA v3?

Proxies residenciais rotativos ou sticky são o ponto ideal. IPs de ISPs domésticos têm a reputação mais alta no modelo do Google. Proxies móveis (4G/5G) têm reputação ainda maior (0.7–0.9), mas são mais caros. Proxies datacenter, mesmo dedicados e limpos, raramente passam de 0.4. Para sessões longas (login, checkout), use sticky sessions; para volume alto, rotacione entre múltiplos IPs residenciais.

Como evitar bloqueios ao implementar automação com reCAPTCHA v3?

Use um navegador real (Playwright/Puppeteer com stealth), roteie por proxy residencial limpo (ex.: ProxyHat com user-country-US), alinhe locale/timezone/país, implemente movimento de mouse e digitação com atrasos humanos (80–150ms por tecla), respeite rate limits (1–5 ações/minuto por IP), e gere um novo token por ação. Nunca reuse tokens — eles expiram em 2 minutos. Documente autorização legal para cada alvo.

É legal automatizar sites que usam reCAPTCHA v3?

Depende do contexto e da jurisdição. QA em seu próprio site, pentest autorizado por contrato, e pesquisa de SERP respeitando robots.txt são tipicamente legítimos. Acessar sistemas sem autorização pode violar o CFAA nos EUA e o GDPR na Europa. Coletar dados pessoais sem base legal pode gerar multas de até 4% do faturamento global sob o GDPR. Consulte um advogado antes de automatizar sites de terceiros.