Why your Cloudflare Turnstile token works in the browser ...

Why your Cloudflare Turnstile token works in the browser but 403s from requests

You solved the Turnstile widget. You can see the token in the page. You copy it into your script, POST the form from requests, and the server hands you back a 403 — or a JSON body with "success": false. The token clearly worked a second ago in the browser, so what changed?

Short answer: a Turnstile token is not a password you can carry around. It's a one-time, short-lived proof bound to a very specific context, and replaying it from a different context is exactly what it's designed to reject. Below is what that context is, how to tell which constraint you're hitting, and the fix for each.

The real scenario

You're automating a flow on a Cloudflare-protected site. There's a cf-turnstile widget on the form. You get a token one of two ways:

you render the page in a real browser (Playwright/Selenium) and read cf-turnstile-response, or
you hand the sitekey + page URL to a solving service and get a token back.

Either way, you then submit the form with a plain HTTP client requests, httpx, axios) and it fails. The frustrating part: it's intermittent-looking. The reason it feels random is that there are four separate constraints, and you're usually tripping a different one each time.

The four things a Turnstile token is bound to

1. It's single-use

Once Cloudflare validates a token server-side (the siteverify call your target makes), that token is spent. Submit twice, retry, or test it once by hand, and the second use returns false. You get a fresh one per submission.

2. It has a short TTL

Turnstile tokens expire fast — a few minutes. Solve early, do other work, submit later, and the token can be dead on arrival. The widget auto-refreshes in the browser precisely because tokens go stale; a script that grabs the token and sits on it loses that refresh.

3. It's bound to the sitekey and the page URL

Multiple widgets. Some pages embed more than one Turnstile (login + newsletter). Solving the wrong sitekey gives a token the server rejects.
Runtime-injected sitekeys. Many sites inject the sitekey with JS at render time, sometimes rotating it. If you scraped it from static HTML once, it may already be wrong. Read it off the rendered widget.

4. If it's a managed challenge, the browser gets re-checked on submit

This one bites people who "did everything right." A standalone widget issues a token you can submit from anywhere. But Cloudflare's managed challenge re-evaluates the request on submission: TLS/JA3 fingerprint, the cf_clearance cookie, IP reputation. A token minted in a real browser, then replayed from a raw HTTP client with a different fingerprint and no clearance cookie, fails that second check no matter how valid the token is.

How to tell which one you're hitting

Don't guess — read the response.


import requests

resp = requests.post(target_url, data=form, headers=headers)

print(resp.status_code)

print(resp.headers.get("cf-mitigated"))   # present => Cloudflare challenge layer

print(resp.text[:600])                     # body usually names the cause

JSON {"success": false, "error-codes": [...]} from the site's verify endpoint → it's the token (expired/reused/wrong sitekey). Codes are explicit: timeout-or-duplicate, invalid-input-response.
A 403 with a cf-mitigated header + challenge-page body → it's the fingerprint/clearance layer (#4), not the token.
A 403503 with a Cloudflare code like 1020 → a WAF/IP decision; no token solves that.

The fix

For a standalone widget (causes 1–3): solve against the exact sitekey from the rendered widget and the exact page URL; submit immediately (seconds, not minutes); solve once per submission, never reuse. Token flow with a 2Captcha-compatible API (so an existing 2Captcha client is a base-URL change):


import requests, time

API_KEY = "YOUR_API_KEY"

SITEKEY = "0x4AAAAA..."   # read from the rendered widget, not static HTML

PAGEURL = "https://target.example/login"

r = requests.post("https://ocr.captchaai.com/in.php", data={

    "key": API_KEY, "method": "turnstile",

    "sitekey": SITEKEY, "pageurl": PAGEURL, "json": 1}).json()

task_id = r["request"]

token = None

for _ in range(40):

    time.sleep(3)

    res = requests.get("https://ocr.captchaai.com/res.php", params={

        "key": API_KEY, "action": "get", "id": task_id, "json": 1}).json()

    if res["status"] == 1:

        token = res["request"]; break

form["cf-turnstile-response"] = token   # submit RIGHT AWAY — single-use, short-lived

resp = requests.post(PAGEURL, data=form, headers=headers)

For a managed challenge (cause 4): a bare token isn't enough — carry the browser context it was minted in. Keep the cf_clearance cookie; pin the same IP, same User-Agent, and a browser-matching TLS fingerprint from minting through submission (e.g. curl_cffi with impersonate, or submit in the same browser context). Rotating the proxy or switching to a raw-client UA breaks it.

Rule of thumb: match the token to its sitekey+URL, submit before it ages, and keep the fingerprint that solved a managed challenge identical through submission.

Quick gut-check

[ ] Sitekey read from the rendered widget (handles injection / multiple widgets)
[ ] Page URL passed to the solve matches the page you submit to
[ ] Token submitted within seconds, used exactly once
[ ] Checked the response for cf-mitigated / Cloudflare codes (token-layer vs fingerprint-layer)
[ ] Managed challenge: same IP + UA + TLS fingerprint, clearance cookie carried through

Read the response first. Nine times out of ten it tells you whether you're fighting the token or the fingerprint — and those are very different fixes.

推荐订阅源

DEV Community