O reCAPTCHA v3 mudou o paradigma da verificação anti-bot: em vez de desafios visíveis, ele atribui um score contínuo de 0.0 a 1.0 a cada ação do usuário. Entender como funciona a pontuação do reCAPTCHA v3 é essencial para engenheiros de QA, equipes de automação e pesquisadores de anti-bot que precisam operar dentro dos limites legais e técnicos das plataformas. Neste guia, vamos dissecar o motor de risco, os sinais que o Google funde, por que IPs de datacenter colapsam o score e como proxies residenciais como o ProxyHat ajudam a manter a pontuação acima do limite.
Como funciona a pontuação do reCAPTCHA v3: o modelo de score contínuo
O reCAPTCHA v3, introduzido pelo Google em 2018, abandona o clássico "clique nos semáforos". Em vez disso, ele retorna um score de risco por ação via grecaptcha.execute(). Cada chamada inclui um parâmetro action (por exemplo, login, signup, checkout) que identifica o contexto da interação. O score é devolvido no cliente como um número de ponto flutuante entre 0.0 e 1.0, e novamente no servidor após a verificação via siteverify.
O Google agrupa o tráfego em onze buckets de score discretos: 0.0, 0.1, 0.2, …, 0.9, 1.0. Embora o valor retornado seja contínuo, o backend do Google o arredonda internamente para esses buckets ao alimentar modelos de telemetria. Sites podem configurar limiares próprios, mas os padrões típicos observados na prática são:
- Score < 0.3: bloqueio automático ou desafio secundário (frequentemente reCAPTCHA v2 fallback ou verificação por email).
- Score entre 0.3 e 0.6: desafio ou fricção adicional (MFA, CAPTCHA interativo, verificação por SMS).
- Score > 0.6: tráfego permitido sem fricção.
O guia oficial do reCAPTCHA v3 do Google recomenda que cada site calibre seus próprios limiares com base no tráfego histórico. O score é relativo, não absoluto: um 0.7 em um site de e-commerce pode significar algo diferente de um 0.7 em um fórum pequeno.
O fluxo de execução no cliente
Quando a página carrega, o script https://www.google.com/recaptcha/api.js?render=SITE_KEY é injetado. Em seguida, o desenvolvedor chama:
grecaptcha.execute(SITE_KEY, { action: 'login' }).then(token => {
// envia o token para o servidor
fetch('/verify', { method: 'POST', body: JSON.stringify({ token, action: 'login' }) });
});
O token retornado é uma string opaca de aproximadamente 500-800 caracteres com validade de cerca de 2 minutos. O servidor deve consumir esse token imediatamente via siteverify.
Os sinais que o Google funde no motor de risco
O reCAPTCHA v3 não revela oficialmente a lista completa de sinais, mas engenharia reversa, documentação parcial e observações empíricas permitem mapear as principais categorias. O motor combina sinais comportamentais, reputação de IP, características do navegador e o grafo de cookies do Google em um modelo de aprendizado de máquina que produz o score final.
1. Telemetria de interação com a página
O script do reCAPTCHA captura eventos de mouse, scroll e teclado: velocidade do movimento do cursor, pausas entre cliques, padrões de scroll (suave vs. instantâneo), tempo entre keydown e keyup, e a sequência de foco em campos de formulário. Bots que preenchem formulários instantaneamente ou que não geram eventos de mouse recebem scores baixos porque o perfil comportamental diverge de humanos reais.
Pesquisas como o estudo de Sivakorn et al. sobre o reCAPTCHA demonstram que o Google usa modelos de aprendizado treinados em bilhões de interações para distinguir padrões humanos de automatizados. A entropia dos movimentos é um fator significativo.
2. Grafo de cookies do Google
Se o usuário estiver logado em uma conta Google (Gmail, YouTube, Android), o cookie NID e SID vinculam a sessão a um histórico de identidade. Um usuário com conta ativa há anos, com atividade consistente, tende a receber scores altos. Sessões limpas, sem cookies do Google e sem histórico, são tratadas com desconfiança — especialmente quando combinadas com IPs suspeitos.
3. Características do navegador e fingerprints TLS
O reCAPTCHA inspeciona o User-Agent, a lista de plugins, o navigator.languages, a disponibilidade de APIs como WebGL e Canvas, e a consistência entre o UA declarado e os recursos suportados. Mais importante para automação: o Google também coleta a fingerprint TLS do cliente. O JA3/JA4 fingerprint — que codifica a ordem das cifras e extensões TLS — é comparado contra o esperado para o navegador declarado. Um requests em Python, por exemplo, apresenta um JA3 que não corresponde a nenhum Chrome real, e isso é um sinal imediato de automação.
Outros sinais de JavaScript incluem: navigator.webdriver (verdadeiro em Selenium sem stealth), window.chrome ausente em headless puro, e a assinatura do Canvas API que difere entre motores de renderização reais e emulados.
4. Reputação de IP
Este é o ponto crítico para quem usa proxies. O Google mantém um banco de reputação de IPs que classifica endereços por ASN, tipo (datacenter, residencial, móvel), volume de tráfego suspeito observado e histórico de abuso. IPs de datacenter conhecidos (AWS, DigitalOcean, OVH, Hetzner) recebem penalidades severas no score, frequentemente resultando em scores entre 0.1 e 0.3 independentemente do comportamento. O mesmo navegador, os mesmos cookies, os mesmos movimentos de mouse — mas atrás de um IP 54.x.x.x da AWS — colapsam o score.
É por isso que proxies residenciais são necessários: eles apresentam IPs que pertencem a ASNs de ISPs reais (Comcast, AT&T, Vivo, Deutsche Telekom), com reputação de tráfego humano orgânico. O IP-reputation component do reCAPTCHA é um multiplicador que pode elevar ou destruir o score final.
Por que datacenter e IPs marcados colapsam o score
Considere um cenário de teste: você configura um navegador Playwright real, com stealth plugin, movimentos de mouse humanizados, cookies do Google válidos de uma sessão autenticada, e executa uma ação login. Atrás de um IP residencial, o score pode ser 0.8. Atrás de um IP de datacenter, o mesmo setup retorna 0.2. A diferença não está no comportamento — está na reputação do IP.
O Google não publica os pesos exatos, mas testes empíricos da comunidade de segurança mostram que a reputação de IP pode contribuir com 30-50% do score final quando outros sinais são ambíguos. Para um IP recém-flaggado por tráfego de scraping agressivo, o score pode cair para 0.1 mesmo com comportamento perfeito.
| Tipo de IP | ASN típico | Score médio observado | Comportamento necessário |
|---|---|---|---|
| Datacenter (AWS, GCP, Azure) | AS14618, AS15169, AS8075 | 0.1 – 0.3 | Score colapsa mesmo com browser real |
| Mobile (4G/5G) | ASNs de operadoras | 0.5 – 0.8 | Score alto, alta rotatividade natural |
| Residencial (ISP real) | AS7922, AS3352, AS28573 | 0.6 – 0.9 | Score mantido com comportamento humano |
| Residencial flaggado | Qualquer | 0.2 – 0.4 | Score penalizado por histórico de abuso |
É aqui que o ProxyHat entra: com uma pool de proxies residenciais rotativos, você apresenta IPs que pertencem a ISPs reais e que não estão marcados por abuso recente. Isso eleva o componente de reputação de IP e permite que os sinais comportamentais positivos (browser real, cookies, interação humana) efetivamente contribuam para um score acima de 0.6.
Verificação server-side: siteverify, action e hostname
O token gerado no cliente não é o score final. O servidor deve enviar uma requisição POST para https://www.google.com/recaptcha/api/siteverify com três parâmetros:
secret: a chave secreta do site.response: o token recebido do cliente.remoteip(opcional): o IP do cliente.
O JSON retornado inclui:
{
"success": true,
"score": 0.7,
"action": "login",
"challenge_ts": "2026-01-15T12:00:00Z",
"hostname": "example.com",
"error-codes": []
}
Dois campos exigem validação explícita no backend:
- Action deve corresponder: se o cliente executou
grecaptcha.execute(KEY, { action: 'login' }), o servidor deve verificar queresponse.action === 'login'. Se houver mismatch, o token deve ser rejeitado. Um atacante pode capturar um token de uma ação de baixo risco (ex:page_view) e tentar reusá-lo em uma ação de alto risco (ex:checkout). - Hostname deve corresponder: o campo
hostnamena resposta deve bater com o domínio esperado. Tokens gerados emevil.examplenão devem ser aceitos emexample.com.
Um erro comum é confiar apenas em success: true. Sem validar action e hostname, o sistema fica vulnerável a replay attacks cross-site.
Abordagem legítima com ProxyHat: browser real + proxies residenciais
Para automação legítima — QA de acessibilidade, testes de carga autorizados, pesquisa de segurança com consentimento — a estratégia é combinar um navegador real (não headless puro) com proxies residenciais do ProxyHat e interação humanizada. O objetivo não é "burlar" o reCAPTCHA, mas sim apresentar um perfil de tráfego genuíno que o motor de risco classifica como legítimo.
Configuração do proxy no ProxyHat
O ProxyHat usa um gateway único com parâmetros de geo-targeting e sessão no username. Para tráfego residencial nos EUA:
http://user-country-US:SUA_SENHA@gate.proxyhat.com:8080
Para uma sessão fixa (sticky) que mantém o mesmo IP por um período:
http://user-country-US-session-abc123:SUA_SENHA@gate.proxyhat.com:8080
Para SOCKS5:
socks5://user-country-US:SUA_SENHA@gate.proxyhat.com:1080
Consulte a documentação oficial do ProxyHat para detalhes completos de configuração.
Exemplo em Python com Playwright
O exemplo abaixo usa Playwright com um perfil de navegador não-headless, proxy residencial do ProxyHat e interação humanizada. É um padrão apropriado para testes de QA em ambientes de staging que implementam reCAPTCHA v3:
from playwright.sync_api import sync_playwright
import time, random
PROXY = "gate.proxyhat.com:8080"
PROXY_USER = "user-country-US"
PROXY_PASS = "SUA_SENHA"
PROXY_URL = f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY}"
def human_delay(min_s=0.5, max_s=2.0):
time.sleep(random.uniform(min_s, max_s))
with sync_playwright() as p:
browser = p.chromium.launch(
headless=False, # navegador visível = melhor fingerprint
proxy={"server": PROXY_URL}
)
context = browser.new_context(
viewport={"width": 1366, "height": 768},
user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
locale="en-US"
)
page = context.new_page()
page.goto("https://exemplo-com-recaptcha.com/login")
# Interagir como humano: mover mouse, scroll, pausar
page.mouse.move(400, 300)
human_delay()
page.mouse.move(600, 450, steps=20)
human_delay(1.0, 3.0)
page.evaluate("window.scrollBy(0, 200)")
human_delay()
# Preencher formulário com delays entre campos
page.fill("#email", "qa-test@example.com")
human_delay(0.8, 1.5)
page.fill("#password", "senha-segura-de-teste")
human_delay(1.0, 2.0)
# O reCAPTCHA v3 executa automaticamente no submit
page.click("button[type=submit]")
human_delay(2.0, 4.0)
# Verificar resultado
print(page.title())
browser.close()
Pontos críticos para manter o score alto:
- Use
headless=Falseou um modo headless com stealth patching. Headless puro expõenavigator.webdriver=truee ausência dewindow.chrome. - Adicione ruído comportamental: movimentos de mouse com
steps, pausas aleatórias, scroll progressivo. Bots que preenchem 10 campos em 200ms são trivialmente detectáveis. - Use proxies residenciais com geo-targeting consistente: se o site é
.com.br, useuser-country-BR. Um IP alemão acessando um site brasileiro de e-commerce com conta em português é um sinal de anomalia. - Mantenha cookies entre sessões: se possível, reutilize o contexto do navegador para acumular histórico. Sessões completamente limpas a cada requisição são suspeitas.
- Rotacione IPs com moderação: sticky sessions de 10-30 minutos são mais naturais que um IP novo a cada request. Veja locations do ProxyHat para cobrir geografias específicas.
Erros comuns e edge cases
1. Reutilizar tokens
Cada token é válido por aproximadamente 120 segundos e para uma única verificação. Tentar reusar um token gera timeout-or-duplicate no error-codes.
2. Ignorar o parâmetro action
Se o cliente envia action: 'submit' mas o servidor espera action: 'login', o token é válido mas o action não corresponde. Sem validação, você aceita tráfego de contexto errado.
3. Headless sem stealth
Playwright e Puppeteer em modo headless padrão expõem múltiplos sinais: navigator.webdriver, navigator.plugins.length === 0, chrome.runtime ausente. Use playwright-stealth ou puppeteer-extra-plugin-stealth, ou melhor, execute em modo visível.
4. Conflito de JA3/JA4
Mesmo com um browser real, se o tráfego passa por um proxy MITM que termina TLS (como alguns proxies corporativos), a fingerprint TLS apresentada ao Google é a do proxy, não a do browser. O ProxyHat opera como proxy HTTP/SOCKS5 sem terminação TLS, então a fingerprint do navegador é preservada.
5. Volume excessivo por IP
Mesmo IPs residenciais podem ser flaggados se o volume for anômalo. 500 requisições de login em 10 minutos do mesmo IP é um padrão de credential stuffing. Distribua tráfego entre múltiplas sessões e respeite rate limits naturais.
Onde isso é apropriado — e onde não é
Este guia é para automação legítima. Casos apropriados:
- QA de acessibilidade: testar se usuários com leitores de tela conseguem navegar em páginas protegidas por reCAPTCHA v3.
- Testes de carga autorizados: simular tráfego realista contra seu próprio ambiente de staging.
- Pesquisa de segurança com consentimento: auditorias de anti-bot em sistemas que você possui ou tem autorização explícita para testar.
- Monitoramento de SERP: ver SERP tracking e web scraping legítimo respeitando
robots.txte ToS.
Não é apropriado para: criação de contas em massa, credential stuffing, fraude de pagamento, bypass de limites de taxa em serviços de terceiros sem autorização, ou qualquer atividade que viole o Computer Fraud and Abuse Act (CFAA) nos EUA ou o GDPR na União Europeia. O reCAPTCHA v3 é uma medida de proteção; tentar evitá-lo em sistemas que você não possui pode constituir violação de lei e dos termos de serviço.
Para casos de uso legítimos, o ProxyHat oferece planos de proxies residenciais com geo-targeting em mais de 190 países. A combinação de IPs residenciais limpos, navegador real e comportamento humanizado é o que permite que automação legítima seja classificada como tráfego humano pelo motor de risco do Google.
Key Takeaways
1. O reCAPTCHA v3 atribui um score contínuo de 0.0 a 1.0 por ação. Sites tipicamente bloqueiam abaixo de 0.3, desafiam entre 0.3 e 0.6, e permitem acima de 0.6.
2. O motor funde sinais comportamentais, reputação de IP, fingerprints de browser e o grafo de cookies do Google. Nenhum sinal isolado determina o score — é um modelo de ML.
3. IPs de datacenter colapsam o score independentemente do comportamento. Proxies residenciais são necessários para limpar o componente de reputação de IP.
4. A verificação server-side deve validar action e hostname. Confiar apenas em
success: trueé insuficiente e vulnerável a replay attacks.5. Automação legítima combina browser real + proxies residenciais + interação humanizada. Isso não é "bypass" — é apresentar um perfil genuíno que o motor classifica corretamente como humano.
FAQ
O que é a pontuação do reCAPTCHA v3?
O reCAPTCHA v3 retorna um score contínuo de 0.0 a 1.0 para cada ação do usuário, via grecaptcha.execute(). O score reflete a probabilidade de o tráfego ser humano. Sites configuram limiares próprios, mas tipicamente bloqueiam abaixo de 0.3, desafiam entre 0.3 e 0.6, e permitem acima de 0.6.
Por que a pontuação do reCAPTCHA v3 importa para usuários de proxy?
Porque a reputação de IP é um dos sinais mais pesados no motor de risco. IPs de datacenter (AWS, DigitalOcean) recebem scores entre 0.1 e 0.3 mesmo com comportamento perfeito. Proxies residenciais apresentam IPs de ISPs reais, elevando o score e permitindo que sinais comportamentais positivos efetivamente contribuam.
Qual tipo de proxy funciona melhor para o reCAPTCHA v3?
Proxies residenciais são os mais eficazes porque apresentam IPs de ISPs reais (Comcast, AT&T, Vivo) com reputação de tráfego humano. Proxies móveis (4G/5G) também funcionam bem devido à alta rotatividade natural. Proxies de datacenter devem ser evitados para tráfego que precisa passar por reCAPTCHA v3.
Como evitar bloqueios ao implementar automação com reCAPTCHA v3?
Combine proxies residenciais com geo-targeting consistente, um navegador real (não headless puro), interação humanizada com delays e movimentos de mouse, cookies persistentes entre sessões, e rotação de IPs com moderação. Valide sempre action e hostname no server-side. Respeite rate limits naturais e nunca exceda volumes anômalos por IP.
O reCAPTCHA v3 pode ser "burlado"?
Não no sentido de explorar uma vulnerabilidade. O reCAPTCHA v3 é um modelo de ML que classifica tráfego. Automação legítima que apresenta um perfil genuíno (IP residencial, browser real, comportamento humano) recebe scores altos naturalmente. Tentar forçar scores altos com perfis artificiais em sistemas de terceiros sem autorização pode violar leis como CFAA e GDPR.
