Wie reCAPTCHA v3 Scoring funktioniert: Technischer Leitfaden 2026

QA-Engineers und Anti-Bot-Forscher kennen die Frustration: Ihre Automatisierung besteht jede Verhaltensprüfung, doch reCAPTCHA v3 liefert trotzdem einen Score von 0.1. Die unsichtbare Risiko-Engine beobachtet nicht nur, was Sie tun — sie bewertet auch, woher Sie kommen. Zu verstehen, wie reCAPTCHA v3 Scoring funktioniert, entscheidet darüber, ob Sie einen akzeptierten Score von 0.8 oder einen blockierten von 0.2 erhalten.

In diesem technischen Leitfaden analysieren wir das Scoring-Modell, die von Google fusionierten Signale, die Rolle der IP-Reputation und wie legitime Automatisierung — etwa für autorisierte QA-Tests oder Barrierefreiheits-Audits — einen Score über dem Schwellenwert erreicht.

Wie reCAPTCHA v3 Scoring funktioniert: Das kontinuierliche Risikomodell

Anders als reCAPTCHA v2, das eine binäre Herausforderung ("Ich bin kein Roboter") präsentiert, arbeitet reCAPTCHA v3 vollständig im Hintergrund. Es gibt kein Puzzle, keine Bildauswahl, keine sichtbare Unterbrechung. Stattdessen ruft die Client-Seite grecaptcha.execute(siteKey, {action: 'login'}) auf und erhält asynchron einen Token, der zusammen mit dem Score serverseitig verifiziert wird.

Der recaptcha v3 score ist ein kontinuierlicher Wert zwischen 0.0 und 1.0, wobei 1.0 ein "eindeutig menschlicher" Traffic und 0.0 ein "eindeutig bot-ähnlicher" Traffic bedeutet. Google gruppiert diese Werte intern in 11 Score-Buckets (0.0, 0.1, 0.2, … 1.0), die als diskrete Ausgabe an den Server zurückgegeben werden. Die meisten Websites interpretieren diese Buckets nach drei Schwellenwerten:

• Block: Score < 0.3 — Anfrage wird abgelehnt oder einer harten Challenge unterzogen.
• Challenge: Score 0.3 bis 0.6 — Anfrage wird zugelassen, aber mit zusätzlicher Verifikation (z. B. reCAPTCHA v2-Fallback, E-Mail-Bestätigung).
• Allow: Score > 0.6 — Anfrage wird ohne weitere Hürde akzeptiert.

Diese Schwellenwerte sind nicht von Google vorgegeben — sie liegen im Ermessen des Website-Betreibers. Ein E-Commerce-Login kann bei 0.5 schon blockieren, während ein Newsletter-Anmeldeformular erst bei 0.2 eingreift. Die offizielle reCAPTCHA v3-Dokumentation von Google betont ausdrücklich, dass der Score kontextspezifisch interpretiert werden sollte.

Warum ein recaptcha score 0.3 fatal sein kann

Ein Score von 0.3 ist besonders tückisch: Er liegt genau an der Grenze zwischen "block" und "challenge". Viele Websites setzen den harten Schwellenwert bei 0.3, was bedeutet, dass ein Score von 0.29 Ihre gesamte Anfrage verwirft, während 0.31 Sie gerade noch durchlässt — aber möglicherweise mit einer MFA-Aufforderung oder Rate-Limiting. Diese Schwellenwert-Empfindlichkeit ist der Grund, warum Proxy-Nutzer und Automatisierungs-Teams den Score nicht nur "bestehen" wollen, sondern ihn konsistent über 0.6 halten müssen.

Die Signalquellen: Was Google fusioniert

Der Score entsteht nicht aus einem einzigen Signal. Google betreibt ein maschinelles Lernsystem, das Dutzende von Features fusioniert. Die wichtigsten Kategorien:

1. Verhaltenstelemetrie (Maus, Scroll, Tastatur)

reCAPTCHA v3 injiziert JavaScript, das Interaktionsereignisse auf der Seite aufzeichnet. Dazu gehören:

• Maus-Bewegungsmuster: Geschwindigkeit, Beschleunigung, Richtungswechsel, Bezier-Kurven-Charakteristika. Echte menschliche Bewegungen haben Mikrozittern und unregelmäßige Pausen, die Bot-Bewegungen fehlen.
• Scroll-Verhalten: Timing zwischen Scroll-Events, Scroll-Geschwindigkeit, ob der Benutzer vor dem Absenden scrollt.
• Tastatur-Timing: Zeit zwischen Keydown- und Keyup-Events, Inter-Key-Intervalle, Backspace-Frequenz.
• Seiten-Interaktion: Wie lange verbringt der Nutzer auf der Seite, bevor er die Aktion auslöst? Ein Submit nach 50ms ist hochgradig suspekt.

2. Der Google-Cookie-Graph

Wenn ein Browser ein Google-Konto-Cookie (z. B. von YouTube, Gmail oder der Google-Suche) mitführt, kann reCAPTCHA v3 auf die gesamte Historie dieses Nutzers zugreifen. Ein Nutzer, der seit Jahren ein Google-Konto nutzt, regelmäßige Suchen durchführt und YouTube-Videos schaut, erhält fast immer einen Score über 0.7 — unabhängig vom IP-Pfad. Bot-Sessions ohne Google-Cookies starten mit einem Reputation-Defizit.

3. Browser-Charakteristika und Fingerprinting

Google erfasst eine breite Palette von Browser-Signalen:

• Canvas-Fingerprinting: Die Art, wie der Browser eine Canvas-Rendering-Aufgabe ausführt, ist hardware- und treiberabhängig. Headless-Browser wie Puppeteer oder Playwright im Default-Modus produzieren Canvas-Hashes, die sich von echten Browsern unterscheiden.
• WebGL-Renderer: Der WEBGL_debug_renderer_info-String gibt Aufschluss über die GPU. Ein Headless-Chromium auf einem Cloud-Server meldet oft "SwiftShader" oder "Mesa" statt einer echten GPU wie "NVIDIA RTX 3060".
• JA3/JA4 TLS-Fingerabdruck: Die TLS-Client-Hello-Nachricht enthält die Cipher-Suite-Liste, Extensions und Kurven. Ein Python requests-Client mit urllib3 hat einen völlig anderen JA3-Hash als ein echter Chrome-Browser. Die spezifische Reihenfolge der Cipher-Suites (z. B. TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_GCM_SHA256) und die Extensions (Server-Name-Indication, Application-Layer-Protocol-Negotiation, Supported-Groups) bilden einen einzigartigen Fingerabdruck. Google nutzt diesen Fingerabdruck, um nicht-Browser-Traffic zu identifizieren, selbst wenn der User-Agent-String korrekt ist.
• Navigator-Eigenschaften: navigator.webdriver, navigator.plugins, navigator.languages, navigator.platform — jede Inkonsistenz zwischen diesen Werten ist ein rotes Signal.
• AudioContext-Fingerprinting: Die Verarbeitung eines Audio-Signals durch die Web-Audio-API erzeugt gerätespezifische Unterschiede im Output-Buffer.

4. IP-Reputation

Hier wird es für Proxy-Nutzer kritisch. Google betreibt ein umfangreiches IP-Reputation-System, das Daten aus mehreren Quellen aggregiert:

• ASN-Klassifizierung: IP-Adressen aus Datacenter-ASNs (z. B. AWS AS14618, DigitalOcean AS14061, Hetzner AS24940) werden fast immer als nicht-menschlich eingestuft. Ein Score von 0.1 ist bei Datacenter-IPs die Regel, nicht die Ausnahme.
• Historisches Verhalten: Wenn eine IP in der Vergangenheit Bot-Traffic, Spam oder Missbrauch generiert hat, wird dies im Reputation-System gespeichert.
• Geografische Konsistenz: Wenn die IP in einem Land liegt, das nicht mit dem Browser-Locale oder dem Google-Konto übereinstimmt, sinkt der Score.

Dieser letzte Punkt ist der Grund, warum residential Proxys für reCAPTCHA v3 unverzichtbar sind. Selbst wenn Ihr Browser-Verhalten perfekt ist, Ihr TLS-Fingerabdruck stimmt und Sie menschenähnliche Interaktionen simulieren — eine Datacenter-IP bricht den Score auf 0.1 zusammen. Das IP-Reputation-Signal hat in Googles Modell ein so hohes Gewicht, dass es alle anderen positiven Signale überstimmen kann.

Token-Verifizierung serverseitig: siteverify und Action-Matching

Der Score, den der Client erhält, ist nicht vertrauenswürdig. Google gibt den Token zurück, aber die eigentliche Verifikation erfolgt serverseitig über den siteverify-Endpunkt:

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

Die Antwort enthält:

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

Zwei Felder sind hier besonders wichtig und werden oft übersehen:

Action-Matching

Beim Client-Aufruf wird eine action übergeben (z. B. 'login', 'signup', 'checkout'). Die Server-Antwort enthält dieselbe Action zurück. Wenn die Action im Token nicht mit der erwarteten Action übereinstimmt, sollte der Token verworfen werden. Ein Angreifer könnte einen Token von einer anderen Aktion (z. B. einer niederschwelligen "contact_form"-Action) sammeln und versuchen, ihn für eine kritische "checkout"-Action zu verwenden. Das Action-Matching verhindert diesen Replay-Angriff.

Hostname-Matching

Das hostname-Feld in der Antwort muss mit dem Hostnamen übereinstimmen, von dem die Anfrage stammt. Ein Token, das für example.com ausgestellt wurde, sollte nicht für evil.com akzeptiert werden. Dies schützt vor Cross-Domain-Token-Wiederverwendung.

Beide Prüfungen sind in der offiziellen siteverify-Dokumentation beschrieben, werden aber in der Praxis häufig weggelassen — ein häufiger Sicherheitsfehler.

Warum Datacenter-IPs den Score kollabieren lassen

Um zu verstehen, warum ein recaptcha v3 bypass mit Datacenter-Proxys unmöglich ist, muss man die Gewichtung der Signale verstehen. Googles Modell ist nicht linear — es ist ein Gradient-Boosted-Tree-Modell, in dem bestimmte Features eine sehr hohe Split-Importance haben. Die ASN-Klassifizierung ist eines dieser Features.

Wenn die IP als Datacenter erkannt wird (was durch ASN-Lookup in Echtzeit geschieht), setzt das Modell den Score fast unabhängig von allen anderen Signalen auf einen niedrigen Wert. Das bedeutet:

Die Lösung sind residential Proxys, die IPs aus echten ISP-Bereichen verwenden. Diese IPs sind in ASN-Datenbanken als ISP klassifiziert, nicht als Hosting-Provider. Google kann sie nicht von echtem Endnutzer-Traffic unterscheiden — vorausgesetzt, das Browser-Verhalten stimmt.

Praktische Implementierung: Legitime Automatisierung mit ProxyHat

Nun zum praktischen Teil. Wenn Sie autorisierte QA-Tests durchführen oder Barrierefreiheits-Audits automatisieren, müssen Sie einen Score über dem Schwellenwert erreichen. Hier ist ein bewährter Ansatz mit ProxyHat residential Proxys und Playwright.

Schritt 1: ProxyHat-Konfiguration

ProxyHat bietet residential Proxys über das Gateway gate.proxyhat.com auf Port 8080 (HTTP) bzw. 1080 (SOCKS5). Die Geo-Targeting-Optionen werden im Benutzernamen übergeben:

# HTTP Proxy mit US-Geo-Targeting
http://user-country-US:password@gate.proxyhat.com:8080

# HTTP Proxy mit Stadt-Targeting (Berlin, DE)
http://user-country-DE-city-berlin:password@gate.proxyhat.com:8080

# Sticky Session für konsistente IP
http://user-session-abc123-country-US:password@gate.proxyhat.com:8080

Sticky Sessions sind wichtig für reCAPTCHA v3: Wenn sich Ihre IP zwischen Seitenaufrufen ändert, interpretiert Google dies als Bot-Verhalten. Verwenden Sie eine konsistente Session-ID, um die IP während des gesamten Testzyklus stabil zu halten.

Schritt 2: Browser-Stealth-Konfiguration

Ein nackter Playwright-Browser wird von reCAPTCHA v3 sofort erkannt. Sie müssen:

1. navigator.webdriver auf undefined setzen oder entfernen.
2. Realistische navigator.plugins und navigator.languages injizieren.
3. Canvas- und WebGL-Fingerabdrücke anpassen (z. B. mit playwright-extra und stealth-plugin).
4. Menschliche Interaktionsmuster simulieren (Maus-Bewegungen, Scroll-Pausen).

Schritt 3: Python-Beispiel mit Playwright

from playwright.sync_api import sync_playwright
import time
import random

PROXY = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-country-US-session-qa123",
    "password": "your_password"
}

def human_delay(min_s=0.5, max_s=2.0):
    """Simuliert menschliche Wartezeit."""
    time.sleep(random.uniform(min_s, max_s))

def human_mouse_move(page, x, y):
    """Bewegt die Maus mit menschenähnlicher Bezier-Kurve."""
    page.mouse.move(x, y, steps=random.randint(15, 30))
    human_delay(0.1, 0.3)

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=False,  # Headless wird oft erkannt
        proxy=PROXY,
        args=[
            "--disable-blink-features=AutomationControlled",
            "--no-sandbox"
        ]
    )

    context = browser.new_context(
        viewport={"width": 1920, "height": 1080},
        locale="en-US",
        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"
    )

    # Stealth: webdriver-Flag entfernen
    context.add_init_script("""
        Object.defineProperty(navigator, 'webdriver', {
            get: () => undefined
        });
        Object.defineProperty(navigator, 'plugins', {
            get: () => [1, 2, 3, 4, 5]
        });
        Object.defineProperty(navigator, 'languages', {
            get: () => ['en-US', 'en']
        });
    """)

    page = context.new_page()
    page.goto("https://example.com/login")

    # Menschliche Interaktion simulieren
    human_delay(1.0, 3.0)
    human_mouse_move(page, 500, 300)
    human_delay(0.5, 1.5)

    # Scroll-Verhalten
    page.mouse.wheel(0, random.randint(50, 200))
    human_delay(0.5, 1.5)

    # Formular ausfüllen mit Tastatur-Timing
    human_mouse_move(page, 400, 350)
    page.click("input[name='username']")
    human_delay(0.2, 0.5)

    for char in "testuser":
        page.keyboard.type(char)
        human_delay(0.05, 0.15)

    human_delay(0.3, 0.8)
    page.keyboard.press("Tab")
    human_delay(0.2, 0.5)

    for char in "password123":
        page.keyboard.type(char)
        human_delay(0.05, 0.15)

    human_delay(0.5, 1.5)

    # reCAPTCHA v3 Token abrufen
    token = page.evaluate("""
        return new Promise((resolve) => {
            grecaptcha.execute('SITE_KEY', {action: 'login'})
                .then(token => resolve(token));
        });
    """)

    print(f"reCAPTCHA Token: {token[:50]}...")
    browser.close()

Dieses Beispiel ist bewusst einfach gehalten, zeigt aber die wesentlichen Elemente: einen residential Proxy über ProxyHat, einen echten Browser (nicht headless), Stealth-Injections und menschenähnliche Interaktionsmuster. Die human_delay-Funktion ist entscheidend — konstante 100ms-Verzögerungen sind ein Bot-Signal, während zufällige Verteilungen menschlich wirken.

Schritt 4: Serverseitige Verifikation

import requests

def verify_recaptcha(token, expected_action, expected_hostname, remote_ip):
    """Verifiziert reCAPTCHA v3 Token serverseitig."""
    response = requests.post(
        "https://www.google.com/recaptcha/api/siteverify",
        data={
            "secret": "YOUR_SECRET_KEY",
            "response": token,
            "remoteip": remote_ip
        }
    )
    result = response.json()

    # Kritische Prüfungen
    if not result.get("success"):
        return False, "Token invalid"

    if result.get("action") != expected_action:
        return False, f"Action mismatch: {result.get('action')}"

    if result.get("hostname") != expected_hostname:
        return False, f"Hostname mismatch: {result.get('hostname')}"

    score = result.get("score", 0)
    if score < 0.6:
        return False, f"Score too low: {score}"

    return True, f"Passed with score: {score}"

Häufige Fehler und Edge Cases

Fehler 1: Headless-Modus ohne Stealth

Playwright und Puppeteer im Headless-Modus haben standardmäßig navigator.webdriver = true und fehlende Plugins. reCAPTCHA v3 erkennt dies sofort. Lösung: Verwenden Sie headless=False oder injizieren Sie Stealth-Skripte.

Fehler 2: Inkonsistente IP über Session

Wenn Sie rotierende Proxys ohne Sticky Session verwenden, ändert sich die IP bei jedem Request. Google sieht eine neue IP, die sofort eine Aktion ausführt — das ist ein starkes Bot-Signal. Verwenden Sie immer eine Session-ID im ProxyHat-Benutzernamen.

Fehler 3: Fehlendes Action-Matching

Viele Entwickler prüfen nur success und score, ignorieren aber action und hostname. Dies öffnet die Tür für Token-Replay-Angriffe und Cross-Domain-Missbrauch.

Fehler 4: Zu schnelle Interaktionen

Ein Formular, das in 200ms ausgefüllt und abgesendet wird, ist offensichtlich automatisiert. Selbst mit perfektem Proxy und Stealth-Browser führt dies zu einem niedrigen Score. Ziel sollte eine Gesamtinteraktionszeit von mindestens 3–5 Sekunden sein.

Fehler 5: TLS-Fingerabdruck-Mismatch

Wenn Sie HTTP-Bibliotheken wie requests oder httpx verwenden, stimmt der JA3/JA4-Hash nicht mit einem echten Browser überein. Die Cipher-Suite-Reihenfolge von Python ssl unterscheidet sich grundlegend von Chrome. Verwenden Sie immer einen echten Browser (Chrome, Firefox) für reCAPTCHA v3-Interaktionen.

Wo dieser Ansatz angemessen ist — und wo nicht

Diese Technik ist für legitime Zwecke gedacht:

• Autorisierte QA-Tests: Testen Sie Ihr eigenes reCAPTCHA-Setup, um sicherzustellen, dass echte Nutzer nicht fälschlicherweise blockiert werden.
• Barrierefreiheits-Audits: Automatisierte Tests, die prüfen, ob Screenreader-Nutzer durch reCAPTCHA nicht ausgeschlossen werden.
• Leistungsüberwachung: Verfolgen Sie, wie sich der Score über Zeit entwickelt, um Regressionen zu erkennen.
• Sicherheitsforschung: Akademische Untersuchungen von Anti-Bot-Systemen mit ausdrücklicher Genehmigung.

Dieser Ansatz ist nicht angemessen für:

• Massen-Account-Erstellung oder Credential-Stuffing.
• Betrug, Phishing oder Spam.
• Umgehung von reCAPTCHA auf Websites, für die Sie keine Autorisierung haben.

Im US-Recht kann unbefugter Zugriff auf Computersysteme nach dem Computer Fraud and Abuse Act (CFAA) strafbar sein. In der EU fällt die Verarbeitung personenbezogener Daten unter die DSGVO (GDPR). Stellen Sie sicher, dass Ihre Tests autorisiert sind und Sie die Nutzungsbedingungen der Zielwebsite einhalten.

ProxyHat-spezifische Einrichtung

ProxyHat bietet drei Proxy-Typen, die für unterschiedliche Szenarien geeignet sind. Für reCAPTCHA v3 sind residential Proxys die beste Wahl. Die Einrichtung ist unkompliziert:

1. Erstellen Sie ein Konto unter ProxyHat Pricing.
2. Wählen Sie residential Proxys und konfigurieren Sie Ihre Authentifizierung.
3. Verwenden Sie das Gateway gate.proxyhat.com:8080 mit Geo-Targeting im Benutzernamen.
4. Setzen Sie eine Sticky Session für konsistente IPs während des Testzyklus.

Weitere Ressourcen finden Sie in der ProxyHat-Dokumentation und in unseren Anwendungsfall-Artikeln zu Web-Scraping und SERP-Tracking. Eine Übersicht der verfügbaren Geo-Targets finden Sie auf der Proxy-Locations-Seite.

Key Takeaways

• reCAPTCHA v3 Score ist kontinuierlich (0.0–1.0): Die meisten Websites blockieren bei < 0.3, fordern eine Challenge bei 0.3–0.6 und akzeptieren bei > 0.6.
• IP-Reputation ist entscheidend: Datacenter-IPs kollabieren den Score auf 0.1, unabhängig vom Browser-Verhalten. Residential Proxys sind erforderlich.
• Sticky Sessions sind Pflicht: IP-Wechsel innerhalb einer Session sind ein starkes Bot-Signal. Verwenden Sie user-session-xxx im ProxyHat-Benutzernamen.
• Browser-Stealth ist nicht optional: navigator.webdriver, Canvas-Fingerprint und JA3-Hash müssen mit einem echten Browser übereinstimmen.
• Serverseitige Verifikation muss Action und Hostname prüfen: Nur success und score zu prüfen ist ein Sicherheitsfehler.
• Nur für legitime Zwecke: Autorisierte QA-Tests und Barrierefreiheits-Audits, niemals für Betrug oder Account-Missbrauch.