Human verification and challenges
Human verification and challenges: the built-in modes, what a pass is bound to, and settings for Tencent Captcha, GeeTest, Turnstile and reCAPTCHA v3.
What it does
A challenge policy makes a visitor pass a verification once, after which the node issues a pass credential and requests within its validity go straight through. Verification is done by the node or handed to a third-party service.
When to use it
- After a CC rule matches, verify instead of blocking so real visitors can still get in.
- Put a check in front of login, registration or checkout pages.
- Use different verification services for visitors in different regions.
Where to configure it
In the console: the "Challenge policies" tab on the CC rules page. Create a policy for a site, save, then click "Publish to edge". Rules reference it with the "challenge" action.
Modes
| Mode | Description |
|---|---|
| Delayed | Passes automatically after the minimum delay |
| Click | Passes after the visitor clicks |
| Slider | Passes after the visitor drags the slider |
| CAPTCHA | The visitor enters a code |
| External | Decided by Tencent Captcha, GeeTest v4, Cloudflare Turnstile or Google reCAPTCHA v3 |
The first four have the browser do one proof of work. The slider and CAPTCHA pages offer "Use waiting verification instead", which waits about 5 seconds and completes the proof of work, for screen reader users.
Settings
| Setting | Range | Description |
|---|---|---|
| Priority | 1 to 1000000 | Order when a site has several policies |
| Minimum delay | 5 to 10 seconds | Delayed mode only |
| Challenge validity | 10 to 300 seconds | Time to finish verification after the page opens |
| Pass validity | 1 to 3600 seconds | How long a visitor stays verified |
| Clock skew | 0 to 30 seconds | Allowed time offset |
| Failure window, failures per window | 1 to 3600 seconds, 1 to 20 | A visitor exceeding the failures in the window is blocked temporarily |
| IP binding | None, IP only, User-Agent only, IP and User-Agent | What the credential is bound to; a change of the bound item requires verifying again |
| Proof-of-work difficulty | 12 to 24, default 18 | The browser computes 2 to the power of the difficulty hashes; each step doubles it |
| Bypass paths | Up to 32 | One per line, such as prefix /health/; these paths are not verified |
External verification
Choosing "External" adds a section:
| Setting | Default | Description |
|---|---|---|
| External provider | None | Tencent Captcha, GeeTest v4, Cloudflare Turnstile, Google reCAPTCHA v3 |
| Site key / App ID | None | The application identifier from the provider console |
| Secret | None | At least 16 characters; shown as "configured" after saving, leave empty to keep it |
| Score threshold | 0.5 | reCAPTCHA v3 only, 0.1 to 0.9; scores below it fail |
| When the provider is unavailable | Fall back to built-in verification (click plus computation) | The other option pauses access and asks to retry later |
Add the site domain to the provider console's allowed domains, otherwise the widget reports an error. After changing provider, enter the Site key and Secret again. After saving the credential, click "Publish to edge" to deliver it to nodes.
FAQ
The widget reports an error after saving
Confirm the domain is in the provider's allowed domains and that the Site key and Secret belong to the same application.
Saving the credential failed
The policy itself is saved. The page shows "Retry saving credential"; check and retry.
Built-in or external
Built-in verification is done by the node and needs no third party. External verification is decided by the selected service, its strength depends on that service, and it does not use the node's proof of work.