Come funziona il punteggio reCAPTCHA v3: il modello di scoring invisibile
Se stai leggendo questa guida, probabilmente hai visto il tuo score reCAPTCHA v3 crollare sotto 0.3 nonostante l'automazione sia legittima. Il problema non è il tuo codice: è la reputazione del tuo indirizzo IP. Come funziona il punteggio reCAPTCHA v3 è la domanda centrale per chiunque faccia QA automation, scraping SERP o ricerca anti-bot, perché il sistema di Google non presenta mai una sfida visibile all'utente — restituisce invece un punteggio continuo da 0.0 a 1.0 che il sito proprietario usa per decidere se bloccare, sfidare o lasciar passare la richiesta.
Il punteggio reCAPTCHA v3 viene generato lato client tramite grecaptcha.execute(siteKey, {action: 'submit'}), che restituisce un token crittografato inviato al server backend. Il server chiama siteverify sull'endpoint di Google e riceve in risposta un JSON con il campo score (float 0.0–1.0), il campo action (l'azione dichiarata), hostname, success e una lista di error-codes. Il sito decide poi in base a soglie configurate: tipicamente blocco sotto 0.3, sfida tra 0.3 e 0.6, consenso sopra 0.6. Queste soglie non sono fisse — ogni sito le imposta in base alla propria tolleranza al rischio.
Il punteggio è suddiviso in undici bucket discreti (0.0, 0.1, 0.2, … 1.0) anche se l'API restituisce un float. Google non pubblica i dettagli del modello, ma dalla documentazione ufficiale e dall'analisi della community emerge che il punteggio fonde segnali comportamentali, telemetria del browser, grafo dei cookie Google e reputazione dell'IP. Se l'IP è in una rete datacenter nota o è stato flaggato per abuso, il punteggio collassa indipendentemente dal comportamento dell'utente.
Contesto tecnico: perché reCAPTCHA v3 esiste
Google ha introdotto reCAPTCHA v3 nel 2018 per eliminare le sfide visive (seleziona i semafori, ecc.) che degradavano l'esperienza utente e potevano essere risolte da bot con OCR. Il compromesso: invece di una prova di umanità puntuale, v3 assegna un punteggio di rischio continuo basato su tutto il contesto della sessione. Questo significa che non esiste un singolo “trucco” per superare reCAPTCHA v3 — devi presentare un profilo coerente su più dimensioni contemporaneamente.
Per i team di automazione legittima — QA, accessibilità, ricerca di sicurezza autorizzata — questo è un problema reale. Uno script che gira su un IP datacenter con un browser headless non configurato otterrà quasi sempre un punteggio reCAPTCHA v3 inferiore a 0.3, anche se l'azione è perfettamente legittima. La soluzione non è un “recaptcha v3 bypass” magico, ma la costruzione di un profilo di traffico credibile: IP residenziale, browser realistico, interazioni umane plausibili.
Secondo la documentazione ufficiale di Google reCAPTCHA v3, il punteggio è basato su interazioni dell'utente e può essere interpretato dal sito in modi diversi. Google raccomanda esplicitamente di combinare il punteggio con segnali secondari (email validation, rate limiting) per decisioni di alto valore.
Il modello di scoring: 0.0–1.0 e le soglie tipiche
Il recaptcha v3 score è un float tra 0.0 e 1.0 dove 1.0 indica traffico sicuramente umano e 0.0 indica traffico quasi certamente automatizzato o malevolo. I siti configurano soglie personalizzate, ma i pattern comuni sono:
- Score < 0.3: blocco immediato o richiesta di fallback a v2/Enterprise challenge.
- Score 0.3–0.6: sfida aggiuntiva (email verification, 2FA, challenge visibile).
- Score > 0.6: passaggio diretto, nessuna sfida.
Alcuni siti ad alta sicurezza (banking, ticketing) impostano soglie più aggressive: blocco sotto 0.5 o persino 0.7. Siti con bassa tolleranza al false-positive (e-commerce, lead gen) possono tollerare score fino a 0.3. Il punto chiave: il punteggio non è una decisione, è un input. La decisione spetta al backend del sito.
I undici bucket discreti (0.0, 0.1, …, 1.0) esistono perché Google quantizza il punteggio interno del modello per stabilità e privacy. Non puoi ottenere 0.47 — otterrai 0.4 o 0.5. Questo rende difficile fare tuning fine del tuo profilo: un piccolo cambiamento può spostarti di un intero bucket.
I segnali che Google fonde nel punteggio
Google non pubblica la lista completa dei segnali, ma l'analisi della community e le reverse-engineering pubblicate su blog di sicurezza identificano le seguenti categorie principali:
1. Telemetria comportamentale
- Tempistiche di mouse, scroll e keystroke (inter-arrival time, jitter, accelerazione).
- Eventi di interazione con la pagina: focus, blur, change, submit.
- Durata della sessione prima dell'azione e sequenza di navigazione.
Un bot che carica la pagina e chiama grecaptcha.execute() entro 50ms senza eventi mouse otterrà un punteggio basso. Un profilo umano ha inter-arrival time variabili, micro-pause, correzioni.
2. Grafo dei cookie Google
Se l'utente ha un cookie Google autentico (account loggato, cookie di analytics, cookie pubblicitari), il punteggio migliora significativamente. Questo è il segnale più forte: Google sa chi sei perché hai già interagito con il suo ecosistema. Per l'automazione, questo significa che un profilo browser pulito senza cookie Google parte svantaggiato.
3. Caratteristiche del browser e fingerprint TLS
- User-Agent, Accept-Language, platform, screen resolution.
- Canvas fingerprint, WebGL renderer, audio context fingerprint.
- JA3/JA4 fingerprint TLS: l'ordine delle cipher suite e le estensioni TLS identificano il client TLS. Chrome su Windows ha un JA3 diverso da curl o da Python
requests. Se il tuo User-Agent dice Chrome ma il JA3 è quello di curl, il punteggio crolla. - HTTP/2 fingerprint (SETTINGS frame, priority tree).
Secondo la specifica TLS 1.3 IETF, il client hello include cipher suites in un ordine specifico per implementazione. Strumenti come JA3 di Salesforce hanno reso questa fingerprint una tecnica standard di identificazione client.
4. Reputazione dell'IP
Questo è il punto critico per chi usa proxy. Google mantiene un database di reputazione IP che include:
- Tipo di rete: datacenter (AWS, GCP, Hetzner, OVH), residenziale (Comcast, AT&T, Vodafone), mobile (Verizon, TIM, Vodafone Mobile).
- Cronologia di abuso associata all'IP o alla subnet.
- ASN-level reputation: interi ASN possono essere flaggati.
Un IP datacenter noto (es. AWS us-east-1) otterrà quasi sempre un punteggio basso, perché Google sa che la stragrande maggioranza del traffico automatizzato malevolo proviene da datacenter. Non importa quanto sia realistica la tua telemetria comportamentale — il segnale IP-reputation può da solo trascinare il punteggio sotto 0.3.
Perché i proxy datacenter falliscono e quelli residenziali sono necessari
Il motivo per cui il recaptcha v3 score collassa sui datacenter è semplice: Google non vede mai un essere umano reale navigare da un IP AWS. Il rapporto traffico-umano/traffico-totale su un IP datacenter è quasi zero, quindi il prior bayesiano del modello dice “questo è quasi certamente un bot”. Nessuna quantità di telemetria comportamentale perfetta può compensare un prior così forte.
I proxy residenziali, invece, usano IP assegnati a ISP consumer reali (Comcast, AT&T, Vodafone, ecc.). Google vede traffico umano legittimo da questi IP ogni giorno, quindi il prior è neutro o positivo. Questo non garantisce un punteggio alto — devi comunque avere un browser realistico e telemetria plausibile — ma rimuove il bias negativo più forte.
I proxy mobili sono ancora migliori per punteggi massimi, perché Google tratta le reti mobili come altamente umane (device reali, connessioni cellulari). Tuttavia, per la maggior parte dei casi d'uso di automazione legittima, i residenziali sono sufficienti e più economici.
| Tipo di proxy | Reputazione IP tipica | Score reCAPTCHA v3 atteso* | Costo relativo |
|---|---|---|---|
| Datacenter (AWS, Hetzner, OVH) | Bassa / flaggata | 0.1–0.3 | Basso ($0.5–2/GB) |
| Residenziale (ISP consumer) | Neutra / positiva | 0.5–0.9 | Medio ($3–15/GB) |
| Mobile (rete cellulare) | d>Alta0.7–0.9 | Alto ($10–30/GB) |
*Score atteso con browser realistico e telemetria umana plausibile. Senza questi, anche i residenziali possono scendere sotto 0.5.
Verifica del token server-side: siteverify, action e hostname
Dopo che il client ottiene il token tramite grecaptcha.execute(), lo invia al backend del sito. Il backend chiama siteverify sull'endpoint Google:
POST https://www.google.com/recaptcha/api/siteverify
secret=YOUR_SECRET_KEY
response=TOKEN_FROM_CLIENT
remoteip=USER_IP (opzionale)Google risponde con un JSON:
{
"success": true,
"challenge_ts": "2026-01-15T10:30:00Z",
"hostname": "example.com",
"score": 0.7,
"action": "submit",
"error-codes": []
}Due controlli critici che il backend deve fare e che spesso vengono omessi:
- Match dell'action: il campo
actionnella risposta deve corrispondere all'azione attesa per quel form. Se il sito aspettaaction: "login"ma riceveaction: "submit", deve rifiutare. Un attaccante potrebbe riutilizzare un token valido ottenuto per un'azione diversa. - Match dell'hostname: il campo
hostnamedeve corrispondere al dominio del sito. Un token generato suevil.comcon la stessa site key non deve essere accettato suexample.com.
Senza questi controlli, il sistema è vulnerabile a replay attack cross-action e cross-host. Per l'automazione legittima, questo significa che non puoi riusare un token: ogni execute() genera un token single-use legato all'azione e all'hostname.
Setup ProxyHat per automazione legittima con reCAPTCHA v3
Per ottenere un punteggio reCAPTCHA v3 sopra soglia in modo legittimo, servono tre componenti:
- Proxy residenziale con geo-targeting appropriato (es. US per un sito US).
- Browser realistico (Chrome/Firefox non headless, o headless con stealth patch) con JA3/JA4 coerente.
- Interazioni umane plausibili: delay variabili, mouse movement, scroll prima del submit.
Configurazione del proxy ProxyHat
ProxyHat fornisce proxy residenziali via gateway gate.proxyhat.com sulla porta 8080 (HTTP) o 1080 (SOCKS5). Il geo-targeting e le sessioni sticky si impostano nel username:
# HTTP proxy, US residential, sticky session
http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080
# SOCKS5 proxy, German residential, city-level
socks5://user-country-DE-city-berlin:pass@gate.proxyhat.com:1080Consulta la documentazione ProxyHat per il formato completo dei parametri username.
Esempio Python: Playwright + ProxyHat + interazioni umane
Questo esempio usa Playwright con Chrome (non headless puro) e ProxyHat residenziale US per caricare una pagina con reCAPTCHA v3, simulare interazioni umane e ottenere un token con score sopra soglia:
from playwright.sync_api import sync_playwright
import time, random
PROXY = "http://user-country-US-session-qa01:pass@gate.proxyhat.com:8080"
def human_delay(min_s=0.3, max_s=1.2):
time.sleep(random.uniform(min_s, max_s))
with sync_playwright() as p:
browser = p.chromium.launch(
headless=False, # headless=True riduce il score
proxy={"server": PROXY}
)
context = browser.new_context(
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",
viewport={"width": 1920, "height": 1080},
locale="en-US"
)
page = context.new_page()
page.goto("https://example.com/login")
# Simula scroll e mouse movement umani
human_delay(1.0, 2.5)
page.mouse.move(random.randint(100, 800), random.randint(100, 600))
human_delay()
page.mouse.wheel(0, random.randint(50, 200))
human_delay()
# Compila il form con typing realistico
page.fill("#email", "test@example.com", delay=50)
human_delay()
page.fill("#password", "secret123", delay=30)
human_delay(0.5, 1.5)
# Esegui reCAPTCHA v3 e ottieni il token
token = page.evaluate('''() => {
return new Promise((resolve) => {
grecaptcha.execute(SITE_KEY, {action: "login"})
.then(token => resolve(token));
});
}''')
print(f"Token reCAPTCHA: {token[:40]}...")
# Ora invia token al backend per siteverify
browser.close()Punti chiave per mantenere il punteggio alto:
- Non usare headless puro: Chrome headless ha fingerprint diversi (navigator.webdriver, missing plugins). Usa
headless=Falseo librerie comeundetected-chromedriveroplaywright-stealth. - Sessioni sticky: usa
-session-abc123nel username per mantenere lo stesso IP durante la sessione. Rotazioni per-request possono apparire sospette a Google. - Delay variabili: timing costanti (es. sempre 500ms) sono una firma bot. Usa jitter uniforme o distribuzioni log-normal.
- Geo-targeting coerente: se il sito è US, usa
-country-US. Un IP tedesco su un sito US-only può abbassare il punteggio.
Per i parametri di connessione completi e le opzioni di geo-targeting, vedi la pagina locazioni ProxyHat.
Errori comuni e edge case
1. Usare curl o requests per ottenere il token
Non funziona. grecaptcha.execute() richiede JavaScript eseguito in un browser reale con DOM, canvas, WebGL. curl non ha questi. Anche se estrai il token da una chiamata precedente, è single-use e legato all'hostname.
2. Headless senza stealth patch
Chrome headless default espone navigator.webdriver = true e manca di plugin, audio context, e ha un JA3 leggermente diverso. Questo basta per far crollare il punteggio a 0.1–0.2 anche con proxy residenziale.
3. Rotazione IP troppo frequente
Se cambi IP a ogni request all'interno della stessa sessione browser, Google vede sessioni brevissime da IP diversi — pattern tipico di botnet. Usa sessioni sticky di almeno 5–10 minuti per automazione legittima.
4. Ignorare il match action/hostname lato server
Se stai testando il tuo stesso sito, assicurati che il backend verifichi action e hostname. Se non lo fa, il tuo test non è rappresentativo di un deployment reale e potresti avere false positive di successo.
5. Score che varia nel tempo
Il punteggio reCAPTCHA v3 non è deterministico. Lo stesso profilo può ottenere 0.7 oggi e 0.4 domani, perché Google aggiorna il modello e la reputazione IP evolve. Monitora il punteggio nel tempo, non fare test una tantum.
Casi d'uso appropriati e caveat legali
L'approccio descritto è appropriato per:
- QA automation autorizzata: testare il tuo sito o un sito per cui hai un contratto di testing.
- Ricerca di sicurezza autorizzata: pentesting con scope scritto, bug bounty program.
- Automazione accessibilità: verificare che i form siano usabili con assistive technology.
Non è appropriato per: creazione account massiva, bypass di limiti di rate, frode pubblicitaria, ticketing/sneaker botting contro ToS, scraping di contenuti protetti senza autorizzazione.
Il Computer Fraud and Abuse Act (CFAA) degli Stati Uniti criminalizza l'accesso non autorizzato a sistemi informatici, e “non autorizzato” può includere la violazione dei ToS di un sito. In Europa, il GDPR si applica al trattamento di dati personali anche durante scraping o testing. Se raccogli dati personali (email, nomi, IP), hai bisogno di base giuridica (consenso, interesse legittimo) e rispetto dei principi di minimizzazione.
Regola pratica: se non sei sicuro di avere autorizzazione scritta per automatizzare l'interazione con un sito, non farlo. Il rischio legale supera il beneficio tecnico.
ProxyHat-specific: pricing e use case
ProxyHat offre proxy residenziali, mobili e datacenter. Per automazione con reCAPTCHA v3, i residenziali sono il default raccomandato. Vedi la pagina prezzi ProxyHat per i piani correnti.
Per use case specifici di web scraping e SERP tracking, consulta web scraping e SERP tracking.
Key Takeaways
- reCAPTCHA v3 restituisce un punteggio 0.0–1.0, non una sfida visibile. Soglie tipiche: blocco <0.3, sfida 0.3–0.6, allow >0.6.
- Il segnale IP-reputation è il più forte: IP datacenter flaggati trascinano il punteggio sotto 0.3 indipendentemente dal comportamento.
- I proxy residenziali sono necessari per rimuovere il bias negativo dell'IP datacenter, ma non sufficienti da soli.
- Browser realistico + interazioni umane sono altrettanto importanti: headless puro, JA3 incoerente, timing costanti abbassano il punteggio.
- Token è single-use e legato a action + hostname: non puoi riusarlo e il backend deve verificare entrambi.
- Usa solo per automazione autorizzata: QA, pentesting con scope, accessibilità. Il CFAA e il GDPR si applicano.
FAQ
Come funziona il punteggio reCAPTCHA v3?
reCAPTCHA v3 assegna un punteggio continuo da 0.0 a 1.0 basato su segnali comportamentali (mouse, scroll, keystroke), telemetria del browser, grafo dei cookie Google e reputazione dell'IP. Il punteggio viene restituito via grecaptcha.execute() lato client e verificato lato server con siteverify. Soglie tipiche: blocco sotto 0.3, sfida tra 0.3 e 0.6, consenso sopra 0.6.
Perché il punteggio reCAPTCHA v3 importa per chi usa proxy?
Il punteggio reCAPTCHA v3 dipende fortemente dalla reputazione dell'IP. I proxy datacenter (AWS, Hetzner, OVH) hanno reputazione bassa perché Google non vede traffico umano legittimo da quelle reti. Questo trascina il punteggio sotto 0.3 anche con automazione legittima. I proxy residenziali rimuovono questo bias, permettendo all'automazione legittima di ottenere punteggi sopra soglia.
Quale tipo di proxy funziona meglio per reCAPTCHA v3?
I proxy mobili offrono i punteggi più alti (0.7–0.9) perché le reti cellulari sono trattate come altamente umane. I proxy residenziali sono la scelta consigliata per la maggior parte dei casi d'uso: offrono punteggi 0.5–0.9 a un costo inferiore. I proxy datacenter non sono adatti: il punteggio tipico è 0.1–0.3 anche con browser realistico.
Come evitare i blocchi quando si implementa automazione con reCAPTCHA v3?
Usa proxy residenziali con geo-targeting coerente, un browser non-headless con stealth patch (JA3/JA4 coerente, navigator.webdriver nascosto), interazioni umane plausibili (delay variabili, mouse movement, scroll), e sessioni sticky di almeno 5–10 minuti. Non usare curl o requests per ottenere il token: serve un browser reale con JavaScript eseguito. Monitora il punteggio nel tempo perché non è deterministico.
È legale usare tecniche per superare reCAPTCHA v3?
Dipende dal contesto. Per QA automation sul tuo sito o pentesting autorizzato con scope scritto, sì. Per accesso non autorizzato a siti di terzi, il CFAA negli Stati Uniti e leggi simili in altre giurisdizioni possono applicarsi. Il GDPR si applica se raccogli dati personali. Ottieni sempre autorizzazione scritta prima di automatizzare interazioni con siti di terzi.
