Skip to content
Blog

CAPTCHA loop: why it repeats and how to fix it

A CAPTCHA challenge is a check a site runs before it lets a request through. Why visitors get stuck in repeat challenges, and how to find the failing step.

Frederick Jahn
Published Updated
CAPTCHA loop: why it repeats and how to fix it

A CAPTCHA challenge is a check a website runs before it lets a request through. It can be a visible puzzle, a checkbox, or an invisible test that runs in the browser. A visitor who passes should get a token or cookie and continue without seeing the check again.

A bot-challenge loop happens when the user repeatedly reaches verification without obtaining usable access to the intended page or action. Diagnose the transition that fails: challenge loading, completion, server validation, state persistence, or the next request's policy decision.

Do not begin by disabling protection for every visitor. First capture one reproducible failure with its time, route, browser version, and request reference.

Cloudflare's challenge troubleshooting documentation lists browser and network conditions that can interrupt completion. A failed challenge is therefore not proof that the visitor is automated.

Follow one attempt all the way through

Use an authorized test session and the normal public entry point. Record whether the challenge loads, whether the completion callback runs, whether the server receives evidence, and which response follows.

Keep tokens and cookies out of support tickets. If a network trace is necessary, redact it and share it only through the approved investigation channel. A screenshot of a successful widget may help describe the symptom, but it does not show server validation.

Last successful transitionInspect next
Page displayedScript loading and browser execution
Challenge completedEvidence submission to the application
Evidence receivedServer verification result and timeout handling
Verification acceptedState set for the correct browser context
State sent on next requestPolicy ordering and scope
Intended page loadedWhether a later action starts verification again

This sequence narrows the search. Without it, client and server teams can both report that their part “worked” while the user remains stuck.

Check expiry and duplicate submission

If the integration uses a one-time token, inspect when it was issued and where it was consumed. A long form-completion time, double submit, or retry can create a different state from the simple happy path.

Turnstile's documented tokens expire and can be validated only once. Check the actual provider's semantics; do not reuse a consumed token indefinitely or treat every duplicate as an attack.

Separate a failed verification from an unknown network outcome. Review the provider's supported retry mechanism and the application's handling of a response that never arrives.

Check where browser state is stored and sent

For cookie-based clearance or session state, inspect the attributes and the host that receives the next request. MDN's Set-Cookie reference explains that a host-only cookie is sent to the host that set it, not automatically to sibling subdomains.

Also review path, secure transport, expiry, and cross-site behavior as applicable. Do not broaden cookie scope or remove security attributes simply to make the loop disappear. Establish which origin needs the state and why.

If a reverse proxy changes hosts or redirects between entry points, follow that path explicitly. State that exists in the browser may still be absent from the request the enforcement component evaluates.

Inspect the next rule, not only the first check

A completed challenge can be followed by a separate rule that triggers another challenge. Capture the decision source and configuration version for both requests.

Verify whether the successful state applies to the intended route and action. A token for one action should not silently become permission for every protected operation.

Be careful with console errors. Cloudflare documents diagnostic requests that can fail without blocking challenge completion. Correlate an error with the failed transition rather than assuming the first red line is the cause.

Verify the repair under ordinary failures

Check a slow form submission, a refresh, a duplicate click, and the supported cross-origin path. Confirm the user reaches the original action without losing necessary form state.

If a temporary exception is necessary, make it narrow, expiring, and owned. Preserve unrelated authentication and authorization controls.

Check what your current protection misses

Repeated challenges deserve investigation alongside the automated traffic you want to stop. Centinel works alongside your existing CDN or WAF and applies allow, challenge or block policy through your existing edge.

Request a free site audit to see which scraping tools get through your current setup. We run real scraping tools against your site, review the results, and email you the report.

Use false-positive investigation when the underlying classification is disputed. For broader product behavior, see the bot-management overview. Close the issue with the failed transition and the repaired behavior, so a future loop does not restart the investigation from scratch.