Cloudflare Challenge Solver

Cloudflare Challenge is an intermediate check that Cloudflare displays before granting access to a protected page when a WAF rule, Bot Management or rate limiting deems the request suspicious (for example, based on TLS fingerprint, IP reputation, or behavioral signals). While the check is in progress, the visitor sees an intermediate "Just a moment…" page. If the check is passed successfully, Cloudflare issues a cf_clearance cookie — it is tied to the visitor and device and is valid for a limited time — after which the browser gains access to the original page.

All three rely on client-side signals from the browser. JS Challenge (non-interactive) runs in the background, typically in less than five seconds; if it is not passed, Cloudflare shows another challenge page. Managed Challenge lets Cloudflare choose the check dynamically from request characteristics and browser signals, up to an interactive step. Turnstile is an embeddable widget that returns a token to be validated through the Siteverify API; with the optional pre-clearance it can also issue a cf_clearance cookie.

A repeated challenge or a 403 means the request has no valid cf_clearance cookie, the cookie has expired, or the request comes from a different visitor or device than the one the cookie was issued to. Even a valid cookie does not guarantee access: Cloudflare maintains Precursor clearance — a continuous reassessment of session behavior that can lower or reset the clearance level and trigger a repeated challenge if the traffic pattern starts to look suspicious.

CapMonster Cloud solves the task asynchronously through two API calls: createTask with the task parameters, followed by polling getTaskResult until the solution is ready. Depending on the task type, the service returns either a token — which is inserted into the callback without a proxy — or a cf_clearance cookie, for which a proxy is mandatory. You then pass the resulting value in the Cookie: cf_clearance=<value> header of regular HTTP requests, or set it in the browser context — after which the protected page opens without manually passing the check.

Send a POST request to createTask with your clientKey (API key) and the task parameters, wait for the result to be ready by polling getTaskResult (until the status is ready), then use the resulting token or cookie in your HTTP client or browser automation. For ready-made integrations, use the official SDKs in the CapMonster Cloud repositories on GitHub — they wrap the createTask / getTaskResult cycle into a single call.

A proxy is mandatory only for the task that returns a cf_clearance cookie. In the official examples the same proxy is then used for the following requests. For a token result no proxy is required — CapMonster Cloud uses its built-in proxies by default (if you whitelist by IP, add 65.21.190.34). Supported types: http, https, socks4, socks5; transparent proxies and proxies on local machines are not allowed.

Yes. For n8n, there is an official CapMonster Cloud node — installed from the interface or via npm install @zennolab_com/n8n-nodes-capmonstercloud on self-hosted instances. In other cases, your code first makes a regular HTTP request to the CapMonster API (via requests, axios, or any other HTTP client), and then the result is passed to the browser framework (Selenium, Playwright, Puppeteer, etc.) using its own method. The cf_clearance cookie needs to be set with this method before navigating to the protected URL — then the browser will open the page with an already valid check, without a repeated challenge.

Solving Cloudflare Challenge is a technical operation, and its lawfulness depends on how the resulting access is used, not on the tool itself. CapMonster Cloud is intended for legal automation — testing, monitoring, and collecting publicly available data — while responsibility for compliance with the law and with the target resource's Terms of Use rests with the user.