why your reCAPTCHA v3 score is low

#recaptcha #proxy #webscraping #python

If your reCAPTCHA v3 score comes back at 0.1 or 0.3 no matter what solver you throw at it, the solver usually isn't the problem - your IP is. The v3 score is a risk verdict Google assigns mostly from network reputation, and no fingerprint trick overrides a blacklisted datacenter range. This post explains what the score measures, which parts a solver controls, and how to stop blaming the wrong layer.

what the v3 score actually is

reCAPTCHA v3 never shows a checkbox. It runs in the background, watches the session, and returns a float between 0.0 and 1.0 with every token. 1.0 means "almost certainly human", 0.0 means "almost certainly a bot".

The score is not pass/fail. The site owner picks the threshold, and you never see it. A login form might reject anything under 0.7; a low-stakes newsletter signup might accept 0.3. So "my score is 0.5" is meaningless until you know what the target site does with it.

That also means the same token can succeed on one site and bounce on another. You're not solving a captcha - you're trying to clear a threshold you can't read.

why the score is mostly your IP

Google scores the request, not just the widget. The single biggest input is the network the request comes from.

Rough tiers, from what's observable in practice:

Datacenter IPs (AWS, GCP, OVH, Hetzner ranges): capped low. Often 0.1-0.3 even with a flawless device fingerprint. Google maintains these ranges and discounts them by default.
Flagged or overused residential proxies: mid. If a proxy IP has been hammered by every scraper on the same provider, its reputation is already burned.
Clean residential / mobile IPs: this is where 0.7+ becomes reachable. Mobile carrier IPs (rotating behind CGNAT) tend to score highest because real humans share them.

This is why a solver that hits 0.7 on a clean residential proxy drops to 0.2 the moment you point it at a datacenter exit. Nothing about the client changed. The IP did.

If you take one thing from this post: fix the proxy before you blame the solver.

what a solver can and can't move

A solver controls the client side of the score. CapBypass sends each token with a coherent, real-device signal profile - a consistent device fingerprint plus human-shaped timing and a matching pageAction. That moves the client-derived portion of the score from "obvious automation" up to "ordinary user".

What no solver can do:

Launder a datacenter IP into a residential reputation.
Raise the score above whatever ceiling Google has already assigned your network range.
Change the site's threshold.

So the model is: the solver sets your ceiling, your proxy sets your floor. Bring a clean IP and the signal profile can actually reach it. Bring a burned datacenter IP and you've capped yourself before the first request.

solving v3 the right way

Because the IP is the dominant factor, you almost always want the proxied task type for v3, not proxyless. ReCaptchaV3Task requires you to pass your own proxy - and the gateway enforces it. Submit a proxied task with no proxy field and you get:

{ "errorId": 1, "errorCode": "PROXY_REQUIRED", "errorDescription": "..." }

That's deliberate. For v3 the proxy is part of the solve, not an afterthought. Here's the full create request with curl:

curl -s https://api.capbypass.pro/createTask \
  -H 'Content-Type: application/json' \
  -d '{
    "clientKey": "YOUR_API_KEY",
    "task": {
      "type": "ReCaptchaV3Task",
      "websiteURL": "https://example.com/login",
      "websiteKey": "6Lc...your-site-key",
      "pageAction": "login",
      "proxy": "host:port:user:pass"
    }
  }'

The proxy string is host:port:user:pass. pageAction must match the action the page actually fires - more on that below. The response hands back a task id:

{ "errorId": 0, "taskId": "5f9b...-uuid" }

Then poll getTaskResult until status flips to ready:

curl -s https://api.capbypass.pro/getTaskResult \
  -H 'Content-Type: application/json' \
  -d '{ "clientKey": "YOUR_API_KEY", "taskId": "5f9b...-uuid" }'

{
  "status": "ready",
  "solution": { "gRecaptchaResponse": "03AGdBq25..." }
}

gRecaptchaResponse is the token you submit to the target site exactly as a real client would - in the form field or request body the site expects.

The same flow in Python with the Python SDK:

import os
from capbypass import CapBypass

client = CapBypass(api_key=os.environ["CAPBYPASS_API_KEY"])

result = client.solve({
    "type": "ReCaptchaV3Task",
    "websiteURL": "https://example.com/login",
    "websiteKey": "6Lc...your-site-key",
    "pageAction": "login",
    "proxy": "host:port:user:pass",
})

token = result["solution"]["gRecaptchaResponse"]
# submit `token` as g-recaptcha-response in your login request

Prefer TypeScript or Go? The same task works through the TypeScript and Go SDKs.

If you genuinely can't supply a proxy, ReCaptchaV3TaskProxyLess routes through the CapBypass IP pool - but you inherit whatever reputation that pool's exit has for your target. For score-sensitive endpoints, a clean proxy you control beats a shared pool.

For the full task schema, including the Enterprise variants, see the reCAPTCHA v3 docs. Both createTask and getTaskResult are covered in the API reference.

Bonus: +5% credits on every top-up

New to CapBypass? Apply code WELCOME_2026 at checkout for an extra 5% in credits on every top-up, with no minimum and no expiry. Redeem it on the top-up page and run the ReCaptchaV3Task flow above on us.

debugging a score that won't go up

Work down this list before you open a support ticket:

Check the proxy class first. Run your proxy through an IP-reputation lookup. If it resolves to a datacenter ASN, that's your ceiling. Swap to clean residential or mobile and re-test before changing anything else.
Match pageAction to the real action. v3 scores are action-scoped. If the page fires grecaptcha.execute(siteKey, {action: 'login'}) and you submit pageAction: "homepage", the action mismatch alone drags the score down. Read the page's JS and copy the exact string.
Use the token once, fast. v3 tokens expire after ~2 minutes and are single-use. A token sitting in a queue for 90 seconds may verify as stale. Solve, then submit immediately.
Confirm v3 vs Enterprise. Enterprise sitekeys (loaded from enterprise.js / recaptcha/enterprise.js) need ReCaptchaV3EnterpriseTask, not ReCaptchaV3Task. Wrong family = wrong solve path.
Stop reusing one IP across thousands of solves. Even a clean residential IP degrades if you route every request through it. Rotate.

If you've cleared all five and still floor out, the target's threshold may simply be higher than any score that network can earn - at which point the fix is a better proxy, not a better solver.

faq

Is a higher score always better?
For you, yes - a higher score clears more thresholds. But you can't force an arbitrary score; you can only remove the things dragging it down. The realistic goal is "high enough for this site's threshold", not 1.0.

Why does the same setup score differently on two sites?
Each site sets its own threshold and fires its own action. Same token quality, different bar. Tune pageAction per site.

Will a proxyless task get me a good v3 score?
Sometimes, but you're gambling on the pool exit's reputation for your specific target. For score-sensitive flows, supply your own clean proxy with ReCaptchaV3Task.

Does the device fingerprint matter at all?
Yes - that's the half a solver controls. A broken or inconsistent fingerprint caps you low even on a great IP. CapBypass sends a coherent real-device fingerprint so the client side isn't the thing holding you back. The IP is the other half, and that half is on you.

Originally published on capbypass.pro. CapBypass is an AI-powered captcha-solving API for reCAPTCHA, hCaptcha, Cloudflare Turnstile and AWS WAF.