Come funziona il punteggio di reCAPTCHA v3: guida tecnica per automation e QA

Se gestisci flussi di automation legittima — testing QA, monitoraggio SERP, ricerca di sicurezza o accessibilità — ti sei sicuramente scontrato con reCAPTCHA v3. A differenza delle versioni precedenti, v3 non presenta nessun challenge visibile: assegna silenziosamente un punteggio di rischio continuo da 0.0 a 1.0 e lascia al backend la decisione di bloccare, sfidare o ammettere il traffico. Comprendere come funziona il punteggio di reCAPTCHA v3 è il primo passo per mantenere i tuoi flussi operativi senza interruzioni.

In questa guida tecnica analizzeremo il motore di scoring, i segnali che Google fusiona, il ruolo critico della reputazione IP e un'implementazione pratica con proxy residenziali ProxyHat che mantiene il recaptcha v3 score sopra soglia.

Come funziona il punteggio di reCAPTCHA v3: il modello di scoring

reCAPTCHA v3 introduce un cambio di paradigma rispetto alle versioni precedenti. Non esistono checkbox, selezione di immagini o puzzle. Il sistema restituisce un punteggio di rischio continuo tra 0.0 e 1.0 per ogni azione eseguita tramite grecaptcha.execute(). Il punteggio è discreto in pratica: Google quantizza il risultato in undici bucket (0.0, 0.1, 0.2, …, 1.0), come confermato dalla documentazione ufficiale di Google.

Il flusso è il seguente:

1. Il client carica lo script reCAPTCHA e invoca grecaptcha.execute(siteKey, {action: 'login'}).
2. Google raccoglie segnali comportamentali e ambientali, restituisce un token al client.
3. Il client invia il token al backend.
4. Il backend chiama siteverify con il token, la secret key e l'IP dell'utente.
5. Google risponde con success: true/false, il score (0.0–1.0), l'action e altri metadati.

Le soglie tipiche configurate dai siti sono:

Range punteggio	Comportamento tipico del sito	Significato
< 0.3	Blocco o challenge hard	Traffico quasi certamente bot
0.3 – 0.6	Challenge soft (email, MFA, v2 fallback)	Traffico sospetto, incerto
> 0.6	Acesso consentito	Traffico probabilmente umano

Un recaptcha score 0.3 è il punto di rottura più comune: molti siti lo usano come soglia minima per consentire l'azione senza challenge aggiuntivo. Sotto 0.3, il backend tipicamente rifiuta la richiesta o impone un secondo fattore. Questo significa che per l'automation legittima, l'obiettivo non è «aggirare» reCAPTCHA, maottenere un punteggio che rifletta un utente reale.

I segnali che Google fusiona per calcolare il punteggio

Google non pubblica l'algoritmo esatto, ma la documentazione, le osservazioni della community e l'analisi del traffico di rete permettono di identificare le principali categorie di segnali:

1. Telemetria comportamentale

Il client reCAPTCHA raccoglie eventi di interazione con la pagina: movimenti del mouse, scroll, timestamp delle pressioni dei tasti, tempo trascorso sulla pagina, sequenza di focus/blur. Un client headless che non genera eventi di mouse o scroll riceve un punteggio basso quasi immediatamente. La mancanza di telemetria è di per sé un segnale negativo.

2. Grafico dei cookie Google

Se il browser ha cookie Google attivi (SID, HSID, SSID, APISID, SAPISID), Google può collegare la sessione a un account o a un profilo con storico di attività. Un utente con cookie Google validi e storico positivo tende a ricevere punteggi più alti (0.7–0.9). Un browser pulito senza cookie Google parte da una posizione di svantaggio.

3. Caratteristiche del browser e fingerprinting

Google raccoglie segnali dal browser che vanno oltre il semplice User-Agent:

• Canvas fingerprinting: il rendering di un canvas produce un hash unico per combinazione di GPU, driver e browser. Un canvas identico a milioni di altre istanze (tipico di ambienti virtualizzati) è un segnale di bot.
• WebGL renderer e vendor: valori come SwiftShader o Mesa indicano ambienti headless.
• Navigator properties: navigator.webdriver = true è il segnale più ovvio per Selenium/Playwright non patchati.
• Screen resolution e color depth: risoluzioni 0x0 o 1x1 indicano headless.
• Font enumeration: l'elenco dei font installati è un fingerprint stabile.

4. Fingerprint TLS (JA3/JA4)

Il fingerprint TLS — l'ordine e i valori delle cipher suite, delle estensioni e delle curve ellittiche presentate nel ClientHello — è uno dei segnali più difficili da contraffare. Come descritto nelle specifiche TLS, il ClientHello è determinato dallo stack TLS del client. Un browser Chrome su Windows produce un JA3 diverso da un browser Firefox su Linux, e strumenti come curl o librerie HTTP producono fingerprint completamente diversi dai browser reali.

Il JA4, evoluzione più recente, aggiunge il fingerprint ALPN e la versione TLS, rendendo la classificazione ancora più granulare. Se il tuo automation tool presenta un JA3/JA4 che non corrisponde al User-Agent dichiarato, Google può abbassare il punteggio anche in assenza di altri segnali negativi.

5. Reputazione dell'IP

Questo è il segnale più critico per chi usa proxy. Google mantiene un database di reputazione IP che classifica gli indirizzi in categorie: residenziali, datacenter, mobile, tor exit node, VPN nota. Un IP datacenter o un IP flaggato come proxy/VPN abbassa il punteggio indipendentemente dal comportamento del browser.

Perché IP datacenter e flagged collassano il punteggio

Il problema è matematico, non opinabile. Se il modello di Google assegna un peso significativo alla reputazione IP — e le osservazioni empiriche indicano che questo peso è tra il 30% e il 50% del punteggio totale — allora un IP datacenter flaggato può trascinare il punteggio complessivo sotto 0.3 anche se tutti gli altri segnali sono perfetti.

In altre parole: puoi avere un browser reale con canvas fingerprint valido, telemetria comportamentale umana, cookie Google attivi e JA3 coerente — ma se l'IP è 104.x.x.x (AWS) o 51.x.x.x (DigitalOcean), il recaptcha v3 score collassa a 0.1 o 0.2.

Questo è il motivo per cui i proxy residenziali sono non negoziabili per automation che interagisce con siti protetti da reCAPTCHA v3:

Tipo di IP	Score reCAPTCHA v3 tipico	Adeguatezza per automation
Residenziale reale	0.7 – 0.9	Ottima — si presenta come utente domestico
Mobile (4G/5G)	0.6 – 0.9	Ottima — NAT carrier, alta rotazione naturale
Datacenter pulito	0.1 – 0.4	Scarsa — flaggato come hosting/cloud
VPN commerciale nota	0.0 – 0.2	Pessima — IP in blacklist pubbliche
Tor exit node	0.0	Pessima — bloccato quasi ovunque

I proxy residenziali come quelli offerti da ProxyHat instradano il traffico attraverso IP assegnati a ISP domestici reali. Google non può distinguere il tuo traffico automation da quello di un utente reale che naviga dalla stessa rete, perché l'IP ha la stessa provenienza ASN di un utente domestico.

Verifica server-side: siteverify e matching action/hostname

Il token restituito da grecaptcha.execute() non è autovalidante. Il backend deve verificarlo chiamando l'endpoint siteverify di Google:

POST https://www.google.com/recaptcha/api/siteverify
  secret=YOUR_SECRET_KEY
  response=TOKEN_FROM_CLIENT
  remoteip=USER_IP_ADDRESS

La risposta JSON include:

{
  "success": true,
  "score": 0.7,
  "action": "login",
  "challenge_ts": "2026-01-15T12:00:00Z",
  "hostname": "example.com",
  "error-codes": []
}

Due controlli sono critici e spesso trascurati:

• Matching dell'action: il valore action nella risposta deve corrispondere a quello passato in grecaptcha.execute(). Se il client invoca {action: 'login'} ma il backend si aspetta 'submit', la verifica fallisce o il punteggio viene ignorato.
• Matching dell'hostname: il campo hostname nella risposta deve corrispondere al dominio registrato per la site key. Un token generato su staging.example.com non è valido per example.com a meno che non sia configurato esplicitamente.

Per l'automation legittima (ad esempio test QA), questo significa che devi usare la site key corretta per il dominio su cui stai testando, e l'action deve essere coerente tra client e backend.

Implementazione pratica con ProxyHat: ottenere un punteggio sopra soglia

Vediamo un approccio pratico per automation legittima — ad esempio test QA su un form di login protetto da reCAPTCHA v3. L'obiettivo è ottenere un recaptcha v3 score ≥ 0.7 combinando proxy residenziali e un browser reale con interazione umano-simile.

Configurazione del proxy

Configuriamo un proxy residenziale ProxyHat con geo-targeting US:

http://user-country-US:PASSWORD@gate.proxyhat.com:8080

Per sessioni sticky (necessarie per mantenere i cookie Google tra richieste):

http://user-country-US-session-qa123:PASSWORD@gate.proxyhat.com:8080

Esempio Python con Playwright

from playwright.sync_api import sync_playwright
import time

PROXY_URL = "http://user-country-US-session-qa123:PASSWORD@gate.proxyhat.com:8080"

def run_qa_test():
    with sync_playwright() as p:
        browser = p.chromium.launch(
            proxy={"server": PROXY_URL},
            headless=False,  # headless = punteggio più basso
            args=[
                "--disable-blink-features=AutomationControlled",
            ]
        )
        context = browser.new_context(
            viewport={"width": 1920, "height": 1080},
            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",
        )
        
        # Patch navigator.webdriver
        context.add_init_script("""
            Object.defineProperty(navigator, 'webdriver', {
                get: () => undefined
            });
        """)
        
        page = context.new_page()
        
        # 1. Navigazione umano-simile: vai alla homepage prima
        page.goto("https://example.com", wait_until="networkidle")
        time.sleep(2)  # pausa umana
        
        # 2. Movimento mouse naturale
        page.mouse.move(150, 300, steps=10)
        page.mouse.move(400, 200, steps=15)
        time.sleep(0.5)
        
        # 3. Scroll graduale
        for i in range(3):
            page.evaluate(f"window.scrollBy(0, {200 * (i+1)})")
            time.sleep(0.8)
        
        # 4. Naviga alla pagina di login
        page.goto("https://example.com/login", wait_until="networkidle")
        time.sleep(1.5)
        
        # 5. Interagisci con i campi del form
        page.fill("#username", "testuser")
        time.sleep(0.3)
        page.fill("#password", "testpass")
        time.sleep(0.5)
        
        # 6. Esegui reCAPTCHA v3 action
        token = page.evaluate("""
            async () => {
                await new Promise(r => setTimeout(r, 500));
                return await grecaptcha.execute(
                    'SITE_KEY_HERE', 
                    {action: 'login'}
                );
            }
        """)
        
        print(f"reCAPTCHA token: {token[:40]}...")
        
        # 7. Invia il form con il token
        # (il backend chiamerà siteverify per verificare)
        
        browser.close()

run_qa_test()

Perché questo approccio funziona

• Proxy residenziale: l'IP ha un ASN domestico, quindi la reputazione IP non penalizza il punteggio.
• Browser reale (non headless): canvas fingerprint, WebGL renderer e proprietà navigator sono autentiche.
• Telemetria comportamentale: movimenti mouse con steps, scroll graduale e pause simulate generano segnali positivi.
• JA3 coerente: Chrome reale con stack TLS nativo produce un fingerprint TLS che corrisponde al User-Agent.
• Sessione sticky: il flag session-qa123 mantiene lo stesso IP, permettendo ai cookie Google di accumulare reputazione tra le richieste.

Nota pratica: un punteggio di 0.7 o superiore richiede tipicamente 3–5 secondi di interazione con la pagina prima di invocare grecaptcha.execute(). L'esecuzione immediata dopo il caricamento della pagina produce punteggi più bassi (0.3–0.5) perché la telemetria comportamentale è insufficiente.

Errori comuni e casi limite

1. Headless browser senza stealth

Playwright e Selenium in modalità headless default espongono navigator.webdriver = true, WebGL renderer = SwiftShader e canvas fingerprint identico a ogni altra istanza headless. Il punteggio crolla a 0.1. Soluzione: usare modalità headful o librerie stealth dedicate.

2. Proxy datacenter «puliti»

Non esistono IP datacenter «puliti» per reCAPTCHA v3. Anche se un IP non è in nessuna blacklist pubblica, Google classifica gli ASN di hosting (AWS, GCP, Azure, DigitalOcean, Hetzner) come datacenter e abbassa il punteggio. Questo è il motivo per cui anche un IP AWS mai usato prima può produrre un punteggio di 0.2.

3. Rotazione IP ad ogni richiesta

Se usi rotazione per-request, ogni richiesta parte da un IP nuovo senza cookie Google. Il punteggio iniziale è tipicamente più basso (0.3–0.5) perché il modello non ha storico. Per azioni sensibili (login, pagamento), usa sessioni sticky di almeno 10–15 minuti per permettere l'accumulo di reputazione.

4. Mismatch tra action e hostname

Se la tua automation genera il token su un dominio diverso da quello registrato per la site key, siteverify restituirà success: false o un punteggio non valido. Verifica sempre che hostname nella risposta corrisponda.

5. Token scaduto

I token reCAPTCHA v3 hanno una validità di circa 2 minuti. Se la tua automation ha latenze elevate tra l'esecuzione di grecaptcha.execute() e la chiamata siteverify, il token scade. Assicurati che il backend verifichi il token entro 60 secondi dalla generazione.

Quando l'automation è appropriata: considerazioni legali ed etiche

È fondamentale chiarire i limiti di questo approccio. Le tecniche descritte sono appropriate per:

• Testing QA autorizzato: verificare che il tuo sito gestisca correttamente i punteggi reCAPTCHA v3.
• Automazione di accessibilità: testare che utenti con assistive technology possano completare i form.
• Ricerca di sicurezza autorizzata: penetration testing con autorizzazione scritta del proprietario del sistema.
• Monitoraggio SERP e price tracking su piattaforme dove i ToS lo consentono esplicitamente.

Non è appropriato per:

• Creazione di account falsi o massiva.
• Aggiramento di misure anti-fraud per transazioni finanziarie.
• Scraping di piattaforme in violazione dei Terms of Service.
• Qualsiasi attività che violi il Computer Fraud and Abuse Act (CFAA) o il GDPR europeo.

Nel contesto del CFAA, l'accesso «non autorizzato» a sistemi protetti può costituire reato federale negli Stati Uniti. Se stai testando un sistema di terzi, ottieni sempre autorizzazione scritta. Nel contesto del GDPR, il trattamento di dati personali tramite automation deve avere una base legittima (Art. 6) e rispettare i principi di minimizzazione dei dati.

Il termine recaptcha v3 bypass è fuorviante: non esiste un «bypass» vero e proprio. L'approccio corretto è presentare segnali coerenti con un utente legittimo, in modo che il motore di scoring assegni naturalmente un punteggio sopra soglia. Questo è qualitativamente diverso dall'aggirare un controllo di sicurezza.

Configurazione ProxyHat per scenari reCAPTCHA

Per scenari che coinvolgono reCAPTCHA v3, ProxyHat offre diverse opzioni rilevanti:

Proxy residenziali con geo-targeting

# Stati Uniti (paese)
http://user-country-US:PASSWORD@gate.proxyhat.com:8080

# Germania, Berlino (paese + città)
http://user-country-DE-city-berlin:PASSWORD@gate.proxyhat.com:8080

# Sessione sticky per accumulo reputazione
http://user-country-US-session-test01:PASSWORD@gate.proxyhat.com:8080

Il geo-targeting è importante perché Google considera la coerenza tra l'IP, la locale del browser e il fuso orario. Un IP tedesco con browser in en-US e timezone America/New_York è un segnale di incongruenza.

Proxy SOCKS5 per connessioni che lo richiedono

socks5://user-country-US-session-test01:PASSWORD@gate.proxyhat.com:1080

Consulta la documentazione ufficiale di ProxyHat per dettagli su parametri avanzati, e la pagina locations per la lista completa dei paesi supportati.

Per carichi di lavoro che richiedono alta concorrenza — ad esempio 100 sessioni simultanee per testing distribuito — i proxy residenziali ProxyHat supportano connessioni parallele con rotazione automatica. Per approfondire i casi d'uso di web scraping e SERP tracking, vedi web scraping e SERP tracking.

Key Takeaways

• reCAPTCHA v3 assegna un punteggio 0.0–1.0 basato su segnali comportamentali, fingerprint del browser, cookie Google e reputazione IP. Le soglie tipiche sono: blocco <0.3, challenge 0.3–0.6, allow >0.6.
• La reputazione IP è un fattore dominante: IP datacenter, VPN e Tor producono punteggi di 0.0–0.2 indipendentemente dal comportamento. I proxy residenziali sono non negoziabili.
• Il fingerprint TLS (JA3/JA4) deve essere coerente con il User-Agent dichiarato. Usa browser reali, non librerie HTTP.
• La telemetria comportamentale conta: movimenti mouse, scroll e pause simulate sono necessari per ottenere punteggi ≥0.7.
• Le sessioni sticky accumulano reputazione: usa lo stesso IP per 10–15 minuti quando possibile.
• Verifica sempre action e hostname nella risposta siteverify: mismatch causano fallimenti silenziosi.
• Usa queste tecniche solo per automation legittima: testing QA autorizzato, ricerca di sicurezza, accessibilità. Mai per fraud o account abuse.

Per iniziare con proxy residenziali ProxyHat e testare i tuoi flussi di automation, visita la pagina prezzi o consulta la documentazione per guide dettagliate.