Jak działa ocena reCAPTCHA v3 w 2026: przewodnik techniczny dla inżynierów QA

Jak działa ocena reCAPTCHA v3: niewidzialny model ryzyka

reCAPTCHA v3 różni się fundamentalnie od swoich poprzedników. Nie wyświetla wyzwania wizualnego, nie prosi o rozwiązanie zagadek z obrazkami, nie przerywa flow użytkownika. Zamiast tego zwraca ciągły wynik ryzyka w skali 0.0–1.0 dla każdej akcji oznaczonej przez wydawcę. Wynik obliczany jest asynchronicznie po stronie klienta przez grecaptcha.execute(), a następnie weryfikowany po stronie serwera przez siteverify. To właśnie ta ciągła ocena — a nie binarny test „człowiek czy bot” — stanowi sedno tego, jak działa ocena reCAPTCHA v3 w 2026 roku.

Każde wywołanie grecaptcha.execute(siteKey, {action: 'submit'}) generuje token, który Google ocenia na podstawie kilkunastu sygnałów i zwraca score w przedziale od 0.0 (na pewno bot) do 1.0 (na pewno człowiek). Google dzieli tę skalę na 11 bucketów scoringowych (0.0, 0.1, 0.2, … 1.0), co oznacza, że wynik jest kwantyzowany do jednego z jedenastu poziomów, mimo że interfejs API prezentuje go jako liczbę zmiennoprzecinkową.

Typowe progi stosowane przez wydawców to:

• Wynik < 0.3 — blokada lub twarda weryfikacja dodatkowa (np. fallback do reCAPTCHA v2 z obrazkami).
• Wynik 0.3–0.6 — wyzwanie soft (często email verification, SMS, lub rate limiting).
• Wynik > 0.6 — przepuszczenie bez interakcji.

Te progi nie są sztywne — każdy wydawca konfiguruje je indywidualnie w konsoli reCAPTCHA Enterprise. Wartość recaptcha score 0.3 jest jednak powszechnie uznawana za punkt krytyczny: poniżej niej większość systemów traktuje ruch jako podejrzany.

Dlaczego ten problem istnieje: kontekst techniczny

Google budowało reCAPTCHA v3 jako system scoringowy, nie detekcyjny. Filozofia jest inna niż w v2: zamiast zadawać pytanie i czekać na odpowiedź, system pasywnie zbiera telemetrię przez całą sesję przeglądarki i ocenia prawdopodobieństwo, że ruch pochodzi od człowieka. To oznacza, że każda interakcja na stronie — od ruchu myszką po tempo scrollowania — jest potencjalnym sygnałem scoringowym.

Model jest trenowany na miliardach sesji z całego internetu. Google widzi wzorce botów na skalę, której żaden pojedynczy wydawca nie posiada. To asymetria informacji: wydawca dostaje tylko wynik liczbowy i metadane (action, hostname, challenge_ts), ale nie dostaje wyjaśnienia, dlaczego wynik jest niski. Ta nieprzezroczystość jest celowa — utrudnia to inżynierom automatyzacji odwrócenie modelu.

Dla inżynierów QA i badaczy anti-bot to oznacza konkretne wyzwanie: nie wystarczy „rozwiązać CAPTCHA”. Trzeba utrzymać wysoki wynik przez całą sesję, co wymaga spójności behawioralnej, reputacji IP i zgodności środowiska przeglądarki.

Sygnały, które Google fuzjonuje w wynik reCAPTCHA v3

Google nie publikuje pełnej listy sygnałów ani wag modelu, ale inżynieria odwrotna i dokumentacja publiczna pozwalają zidentyfikować główne kategorie:

1. Telemetria interakcji ze stroną

Najbogatsze źródło sygnałów. Google mierzy:

• Czas między załadowaniem strony a wywołaniem execute() — boty często wywołują execute w ciągu <500ms od DOMContentLoaded, co jest silnym sygnałem automatyzacji.
• Ruch myszy — trajektorie, prędkość, mikrozaburzenia. Ruchy liniowe lub brak ruchu = bot.
• Scroll — tempo, kierunek, pauzy. Człowiek scrolluje nieregularnie.
• Keystroke timing — interwały między naciśnięciami klawiszy. Boty wpisują formularze w <50ms od początku do końca.
• Click patterns — pozycje kliknięć, liczba kliknięć przed submit.

2. Graf ciasteczek Google

To jest najważniejszy sygnał, o którym wielu inżynierów zapomina. Jeśli użytkownik ma aktywne ciasteczka Google (zalogowany Gmail, YouTube, konto Google), reCAPTCHA widzi całą historię aktywności tego konta. Konto z wieloletnią historią, regularną aktywnością i dobrą reputacją dostaje wynik bliski 1.0 niemal automatycznie.

Brak ciasteczek Google (sesja incognito, czysty profil) nie dyskwalifikuje automatycznie, ale obniża wynik bazowy. Google traktuje nowe sesje z większą ostrożnością.

3. Charakterystyki przeglądarki i fingerprint TLS

Google analizuje środowisko przeglądarki na poziomie, który obejmuje:

• JA3/JA4 fingerprint — kolejność szyfrów w ClientHello TLS. Headless Chrome i biblioteki typu requests mają charakterystyczne JA3, które różnią się od prawdziwego Chrome.
• User-Agent i nagłówki HTTP — spójność między UA a rzeczywistymi capabilities (np. navigator.webdriver, navigator.plugins).
• Canvas fingerprint — renderowanie canvas.toDataURL() różni się między GPU/driverami.
• WebGL renderer string — UNMASKED_RENDERER_WEBGL zwraca nazwę GPU. Headless często zwraca SwiftShader lub Mesa.
• AudioContext fingerprint — charakterystyki przetwarzania audio.

Te sygnały są opisane w publicznej dokumentacji Google reCAPTCHA v3 Developer Guide, choć Google celowo nie szczegółowi ich wag.

4. Reputacja IP

To jest sygnał, który może zdominować wszystkie pozostałe. Jeśli IP jest na liście znanych datacenter, VPN providers, lub TOR exit nodes, wynik spada drastycznie — niezależnie od tego, jak ludzkie jest zachowanie. Google utrzymuje własne bazy reputacji IP, fuzjonując dane z Safe Browsing, Gmail spam detection i innych swoich usług.

W praktyce: ruch z IP datacenter (AWS, DigitalOcean, Hetzner) otrzymuje wynik bazowy obniżony często o 0.2–0.4 punktu względem ruchu z IP rezydencjalnego. To oznacza, że nawet perfekcyjnie ludzka sesja z datacenter IP może utknąć na recaptcha score 0.3 lub niżej.

Dlaczego datacenter IP i oflagowane IP kolapsują wynik

Reputacja IP to nie dodatek do modelu — to fundament. Google widzi, że większość zautomatyzowanego ruchu nadużyć (scraping masowy, account creation at scale, credential stuffing) pochodzi z IP datacenter i znanych ranges VPN. Model jest trenowany na tych danych, więc korelacja „datacenter IP = bot” jest silna i uzasadniona statystycznie.

To prowadzi do paradoksu dla inżynierów automatyzacji: nawet najlepsza emulacja zachowania ludzkiego nie pomoże, jeśli IP jest datacenter. Wynik zostanie spłaszczony do dolnych bucketów, niezależnie od telemetrii myszy, scrollowania czy keystroke timing.

Dlatego proxy rezydencjalne są wymogiem, nie opcją, dla jakiejkolwiek automatyzacji, która musi przejść reCAPTCHA v3. IP rezydencjalne — przydzielone przez ISP zwykłym użytkownikom domowym — ma naturalnie wysoką reputację w modelu Google. Ruch z takiego IP zaczyna z bazowym wynikiem, na którym dopiero telemetria behawioralna może budować.

Warto jednak zaznaczyć: proxy rezydencjalne nie są silver bullet. Jeśli telemetria behawioralna jest fatalna (brak ruchu myszy, execute w 200ms, navigator.webdriver=true), nawet czyste IP rezydencjalne nie podniesie wyniku powyżej 0.6. Proxy rozwiązuje komponent reputacji IP — ale to tylko jeden z filarów modelu.

Weryfikacja tokena po stronie serwera: siteverify

Token wygenerowany przez grecaptcha.execute() jest bezużyteczny bez weryfikacji serwerowej. Flow jest następujące:

1. Klient wywołuje grecaptcha.execute(siteKey, {action: 'login'}) i otrzymuje token.
2. Token wysyłany jest na serwer wydawcy (np. w formularzu POST).
3. Serwer wywołuje https://www.google.com/recaptcha/api/siteverify z parametrami secret, response (token), i opcjonalnie remoteip.
4. Google zwraca JSON z score, action, hostname, challenge_ts, error-codes.

Dwa krytyczne aspekty weryfikacji:

Matching action

Google zwraca action w odpowiedzi siteverify. Serwer wydawcy musi porównać zwrócone action z oczekiwanym. Jeśli klient wywołał execute z action: 'login', a serwer otrzyma action: 'register', powinien odrzucić token. To zapobiega atakom typu token replay, gdzie atakujący zbiera tokeny z jednej akcji i używa ich dla innej.

Matching hostname

Google weryfikuje, czy token został wygenerowany na hoście zgodnym z domeną zarejestrowaną dla tego site key. Jeśli site key jest powiązany z example.com, token z evil.com zostanie odrzucony. To chroni przed cross-site token theft.

Ważność tokena

Tokeny reCAPTCHA v3 są ważne przez około 120 sekund od wygenerowania. Po tym czasie siteverify zwraca false z error-codes: ["timeout-or-duplicate"]. Automatyzacja musi więc przesyłać token do weryfikacji szybko — buforowanie tokenów na później nie działa.

Szczegóły API są udokumentowane w oficjalnej dokumentacji weryfikacji reCAPTCHA.

Praktyczne podejście: ProxyHat + real browser + ludzka interakcja

Poniżej przedstawiam podejście, które utrzymuje wynik reCAPTCHA v3 powyżej progu w legalnych scenariuszach: QA automation, accessibility testing, i authorized pentesting. Kluczowe komponenty:

1. Proxy rezydencjalne ProxyHat — dla reputacji IP.
2. Prawdziwa przeglądarka (Playwright/Puppeteer z headed mode) — dla zgodności fingerprintu TLS i JS.
3. Ludzka interakcja — dla telemetrii behawioralnej.
4. Sticky sessions — dla spójności IP w obrębie sesji.

Konfiguracja ProxyHat

ProxyHat używa prostego formatu uwierzytelniania w nazwie użytkownika. Dla geo-targetingu US:

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

Dla sticky session (stałe IP w obrębie sesji):

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

SOCKS5 na porcie 1080:

socks5://user-country-US-session-qa123:password@gate.proxyhat.com:1080

Python: Playwright + ProxyHat + ludzka interakcja

Poniższy przykład pokazuje kompletny flow: uruchomienie prawdziwego Chrome z proxy rezydencjalnym, nawigacja na stronę z reCAPTCHA v3, ludzka interakcja (ruch myszy, pauzy), wywołanie execute, i odczytanie wyniku.

import asyncio
import random
from playwright.async_api import async_playwright

PROXY_USER = "user-country-US-session-qa001"
PROXY_PASS = "twoje_haslo"
PROXY_HOST = "gate.proxyhat.com"
PROXY_PORT = 8080

async def human_delay(min_ms=300, max_ms=1200):
    await asyncio.sleep(random.uniform(min_ms / 1000, max_ms / 1000))

async def human_mouse_move(page):
    # Symuluj ruch myszy — nieregularne trajektorie
    for _ in range(random.randint(3, 7)):
        x = random.randint(100, 800)
        y = random.randint(100, 600)
        await page.mouse.move(x, y, steps=random.randint(10, 30))
        await human_delay(200, 800)

async def get_recaptcha_score(page, action="submit"):
    score = await page.evaluate(f"""
        async () => {{
            await new Promise(r => grecaptcha.ready(r));
            const token = await grecaptcha.execute(
                '{SITE_KEY}', {{action: '{action}'}}
            );
            return token;
        }}
    """)
    return score

async def main():
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            headless=False,  # headed mode — kluczowe dla fingerprintu
            proxy={{
                "server": f"http://{PROXY_HOST}:{PROXY_PORT}",
                "username": PROXY_USER,
                "password": PROXY_PASS,
            }},
            args=["--disable-blink-features=AutomationControlled"]
        )
        context = await browser.new_context(
            viewport={{"width": 1920, "height": 1080}},
            locale="en-US",
        )
        page = await context.new_page()

        await page.goto("https://example.com/login")
        await human_delay(1500, 3000)  # Czas na załadowanie
        await human_mouse_move(page)     # Telemetria ruchu

        # Wypełnij formularz z ludzkim tempem
        await page.fill("#email", "test@example.com")
        await human_delay(500, 1500)
        await page.fill("#password", "securepass")
        await human_delay(800, 2000)

        await human_mouse_move(page)  # Dodatkowy ruch przed submit

        token = await get_recaptcha_score(page, "login")
        print(f"Token: {{token[:50]}}...")

        # Wyślij token do weryfikacji na swoim serwerze
        # Serwer wywoła siteverify i otrzyma score

        await browser.close()

asyncio.run(main())

Kluczowe elementy, które utrzymują wynik:

• headless=False — headed mode produkuje fingerprint TLS zgodny z prawdziwym Chrome.
• --disable-blink-features=AutomationControlled — usuwa flagę navigator.webdriver.
• Ludzkie opóźnienia (300–1200ms) i ruch myszy — telemetria behawioralna.
• Proxy rezydencjalne US — reputacja IP.
• Sticky session (session-qa001) — spójność IP w obrębie sesji.

Ważne: Ten kod jest punktem wyjścia, nie gotowym rozwiązaniem. Każda strona ma inne progi scoringowe i różne wagi sygnałów. Należy testować na własnych zasobach i dostosować opóźnienia oraz wzorce interakcji.

Weryfikacja serwerowa w Python

import requests

RECAPTCHA_SECRET = "twoj_secret_key"

def verify_recaptcha(token, expected_action, remote_ip=None):
    params = {{
        "secret": RECAPTCHA_SECRET,
        "response": token,
    }}
    if remote_ip:
        params["remoteip"] = remote_ip

    resp = requests.post(
        "https://www.google.com/recaptcha/api/siteverify",
        data=params,
        timeout=10
    )
    result = resp.json()

    if not result.get("success"):
        return False, result.get("error-codes", [])

    if result.get("action") != expected_action:
        return False, ["action-mismatch"]

    score = result.get("score", 0.0)
    return score >= 0.5, score

Funkcja weryfikuje nie tylko success i score, ale też matching action. Bez tego sprawdzenia token zebrany dla akcji register mógłby zostać użyty dla akcji login.

Common mistakes i edge cases

1. Wywołanie execute() zbyt wcześnie

Boty często wywołują grecaptcha.execute() natychmiast po DOMContentLoaded. Google mierzy czas między load a execute — <500ms to silny sygnał automatyzacji. Dodaj opóźnienie 1.5–3 sekundy.

2. Brak ruchu myszy

Nawet z proxy rezydencjalnym i prawdziwą przeglądarką, brak ruchu myszy obniża wynik. Google oczekuje, że człowiek porusza kursorem podczas wypełniania formularza. Zero ruchu = sygnał bot.

3. navigator.webdriver = true

Domyślnie Playwright i Puppeteer ustawiają navigator.webdriver = true. Google wykrywa to jako sygnał automatyzacji. Flag --disable-blink-features=AutomationControlled pomaga, ale nie jest w 100% niezawodna w 2026 — niektóre wersje Chrome nadal przeciekają ten sygnał przez inne API. Należy zweryfikować przez page.evaluate("navigator.webdriver").

4. Niespójność fingerprintu TLS (JA3/JA4)

Nawet z headed Chrome, jeśli używasz biblioteki HTTP (np. requests, httpx) do pobierania tokenów, JA3 fingerprint będzie inny niż prawdziwy Chrome. To jest silny sygnał. Rozwiązanie: używaj tylko prawdziwej przeglądarki (Playwright/Puppeteer), nie mieszań z bibliotekami HTTP.

5. Rotacja IP w środku sesji

Jeśli proxy rotuje IP w środku sesji (np. przy każdym requeście), Google widzi zmianę IP i traktuje to jako sygnał podejrzany. Używaj sticky sessions — ProxyHat obsługuje to przez flagę session-XXX w username.

6. Ignorowanie challenge_ts

Tokeny wygasają po ~120 sekundach. Jeśli automatyzacja buforuje tokeny lub przesyła je asynchronicznie, mogą wygasnąć. Weryfikuj token natychmiast po wygenerowaniu.

Kiedy to podejście jest odpowiednie — a kiedy nie

To podejście jest odpowiednie dla:

• QA automation — testowanie własnych aplikacji z włączonym reCAPTCHA v3.
• Accessibility testing — weryfikacja, czy reCAPTCHA v3 nie blokuje użytkowników z czytnikami ekranu lub klawiaturą.
• Authorized pentesting — testy penetracyjne z pisemną zgodą właściciela systemu.
• Security research — analiza modelu scoringowego w celach akademickich.

To podejście NIE jest odpowiednie dla:

• Mass account creation na platformach, których nie posiadasz.
• Credential stuffing lub brute force.
• Scraping w naruszeniu ToS.
• Fraud, ticketing abuse, sneaker botting.

Aspekt prawny: CFAA i GDPR

W USA Computer Fraud and Abuse Act (CFAA) kategoryzuje nieautoryzowany dostęp do systemów komputerowych jako przestępstwo federalne. Omijanie mechanizmów autoryzacji, takich jak reCAPTCHA, na systemach, do których nie masz pisemnej autoryzacji, może być interpretowane jako naruszenie CFAA. Sprawa Van Buren v. United States (2021) częściowo zawęziła definicję „exceeding authorized access”, ale nie zalegalizowała omijania zabezpieczeń.

W UE RODO (GDPR) wymaga podstawy prawnej dla przetwarzania danych osobowych, w tym danych behawioralnych zbieranych przez automatyzację. Scraping danych osobowych bez zgody lub innej podstawy prawnej może naruszać art. 6 RODO. Więcej informacji znajdziesz w wytycznych Europejskiej Rady Ochrony Danych (EDPB).

Zawsze uzyskuj pisemną autoryzację przed testowaniem systemów, których nie posiadasz. Dokumentuj zakres, cel i metodologię.

ProxyHat: konfiguracja i zasoby

ProxyHat oferuje proxy rezydencjalne, mobilne i datacenter. Dla automatyzacji, która musi przejść reCAPTCHA v3, rekomendujemy proxy rezydencjalne z geo-targetingiem US lub EU.

Szczegóły konfiguracji znajdziesz w dokumentacji ProxyHat. Cennik proxy rezydencjalnych dostępny jest na stronie ProxyHat Pricing. Listę dostępnych lokalizacji znajdziesz na ProxyHat Locations.

Jeśli automatyzacja obejmuje scraping lub SERP tracking, zobacz nasze przypadki użycia: web scraping i SERP tracking.

Najważniejsze wnioski (Key Takeaways)

• reCAPTCHA v3 zwraca ciągły wynik 0.0–1.0 w 11 bucketach, z typowymi progami: blokada <0.3, wyzwanie 0.3–0.6, przepuszczenie >0.6.
• Reputacja IP jest fundamentem — datacenter IP kolapsuje wynik niezależnie od zachowania. Proxy rezydencjalne są wymogiem.
• Telemetria behawioralna (mysz, scroll, keystroke timing) jest drugim filarem — nawet z dobrym IP, brak ruchu myszy obniża wynik.
• Weryfikacja serwerowa musi sprawdzać action i hostname — nie tylko score.
• Tokeny wygasają po ~120 sekundach — weryfikuj natychmiast.
• Legalność jest krytyczna — CFAA i GDPR mają zastosowanie. Używaj tylko z autoryzacją.
• Headed browser + proxy rezydencjalne + ludzka interakcja to trójca, która utrzymuje wynik powyżej progu.

Często zadawane pytania (FAQ)

Czym jest wynik reCAPTCHA v3 i jak jest obliczany?

Wynik reCAPTCHA v3 to liczba zmiennoprzecinkowa w skali 0.0–1.0, kwantyzowana do 11 bucketów, zwracana dla każdej akcji oznaczonej przez grecaptcha.execute(). Google fuzjonuje sygnały behawioralne (mysz, scroll, keystroke timing), graf ciasteczek Google, charakterystyki przeglądarki (JA3/JA4, canvas, WebGL) i reputację IP. Model jest trenowany na miliardach sesji. Niższy wynik = wyższe prawdopodobieństwo, że ruch jest botem.

Dlaczego wynik reCAPTCHA v3 ma znaczenie dla użytkowników proxy?

Reputacja IP jest jednym z najsilniejszych sygnałów w modelu reCAPTCHA v3. Ruch z IP datacenter otrzymuje bazowy wynik obniżony często o 0.2–0.4 punktu, co może spychać go poniżej progu 0.3 niezależnie od zachowania. Proxy rezydencjalne rozwiązuje ten komponent, dając ruchowi start z wyższego bucketu bazowego. Bez proxy rezydencjalnego, automatyzacja niemal na pewno utknie na niskich wynikach.

Który typ proxy działa najlepiej z reCAPTCHA v3?

Proxy rezydencjalne i mobilne działają najlepiej, ponieważ ich IP są przydzielone przez ISP i mają naturalnie wysoką reputację w modelu Google. Proxy mobilne często dają jeszcze wyższe wyniki bazowe, ponieważ ruch mobilny jest traktowany jako bardziej „ludzki”. Proxy datacenter nie jest rekomendowane — IP z ranges AWS, DigitalOcean czy Hetzner są systematycznie oflagowane i kolapsują wynik do 0.1–0.3.

Jak uniknąć blokad przy implementacji automatyzacji z reCAPTCHA v3?

Używaj prawdziwej przeglądarki (Playwright/Puppeteer w headed mode), proxy rezydencjalnego ze sticky session, ludzkiej interakcji (ruch myszy, opóźnienia 300–1200ms, nieregularne scrollowanie), i usuń flagę navigator.webdriver. Weryfikuj token natychmiast (wygasa po ~120s). Nie rotuj IP w środku sesji. Testuj na własnych zasobach z autoryzacją. Nigdy nie używaj do fraudu, credential stuffing, ani naruszeń ToS.

Czy „obejście reCAPTCHA v3” jest legalne?

Omijanie reCAPTCHA v3 na systemach, do których masz autoryzację (własne aplikacje, authorized pentesting, QA testing), jest legalne. Omijanie na systemach bez autoryzacji może naruszać CFAA w USA i RODO w UE. Różnica między „legalnym testowaniem” a „nielegalnym omijaniem” leży w autoryzacji właściciela systemu, nie w samej technice. Zawsze dokumentuj zakres i cel testów.