Cloudflare challenges: managed, JS and Under Attack mode

A Cloudflare challenge is a check page served instead of your content until the browser proves it is human. Managed Challenge, which Cloudflare recommends, picks the lightest check per visitor. JS Challenge runs a script with no clicks. Interactive Challenge asks for a click. Block just refuses. Under Attack mode challenges every visitor to your site.

What a Cloudflare challenge is

A challenge is a pause between the visitor and your page. Cloudflare serves an interstitial page, the visitor's browser runs checks in the background or the visitor clicks once, and then the original request continues to your site. If the check fails, the visitor gets another challenge page instead.

Challenges come from several places: WAF custom rules, rate limiting rules, IP Access rules, Bot Fight Mode, Under Attack mode and Cloudflare's DDoS protection. Cloudflare says it does not use visual puzzles such as picking traffic lights or typing distorted letters.

After a visitor passes, Cloudflare sets a cf_clearance cookie. While it is valid, that visitor is not challenged again. Its lifetime is the Challenge Passage setting in your security settings: 30 minutes by default, and Cloudflare recommends a value between 15 and 45 minutes. Challenge Passage does not apply to rate limiting rules.

One detail explains many "endless challenge" complaints: a Managed Challenge solved from one IP is not valid for a different IP. Visitors on networks that switch IPs mid-session can loop. Browser extensions that change the user agent can cause the same thing.

Managed vs JS vs Interactive Challenge vs Block

Cloudflare gives you four ways to stop a request in a custom rule. They differ in what a person sees and what a script gets.

• Managed Challenge. Cloudflare chooses the check for each request based on browser signals. Most people pass automatically and briefly see "Successful". Visitors with non-human signals may have to click. Cloudflare recommends it for most WAF rules and says not to use the other types unless you have a specific compatibility issue.
• Non-Interactive Challenge (JS Challenge). The browser runs a script and the visitor waits, typically less than five seconds. No clicks. In the API it is called js_challenge.
• Interactive Challenge. The visitor must click a checkbox or button. Cloudflare's own docs say it always recommends Managed Challenge instead.
• Block. No check, no second chance. The request gets a 403 error page. Paid plans can customize that page, and Pro and higher can change the response format and status code.

Note that both the Managed Challenge page and the block page return a 403 status. A 403 with Cloudflare branding is often a challenge, not a ban. Challenge responses also carry the header cf-mitigated: challenge, which is the reliable way to tell them apart.

Why APIs, mobile apps and webhooks fail challenges

A challenge needs a browser. Cloudflare lists curl, wget and other tools without JavaScript as unsupported, and says automation frameworks are not supported for solving production challenges. The challenge also fails when the caller expects a non-HTML response, such as a fetch or XHR request from your own front end, because the reply is an HTML page with a 403 status.

In practice that means a challenge rule that covers the whole site will break:

• payment and shipping webhooks, which can leave orders unpaid in your system;
• a mobile app talking to your API;
• uptime monitors, feed readers and your own data scripts;
• AJAX calls on pages, such as cart updates or search suggestions.

The fix is scope. Write challenge rules for the paths that people use, and put a rule with the Skip action first for your webhook and API paths. For your own single-page app, Cloudflare suggests Turnstile pre-clearance, covered below. This is also the main limit of Bot Fight Mode: it challenges across the whole domain and cannot be skipped by custom rules.

Under Attack mode: what it does and how long to keep it on

Under Attack mode (shown as "I'm Under Attack" in older menus) runs extra checks to help stop layer 7 DDoS attacks. Every visitor in its scope gets a Managed Challenge page first. Validated visitors get through, suspicious traffic is blocked. It is off by default.

Cloudflare calls it one of the last resorts when a zone is under attack and advises using it only during a DDoS attack. It temporarily pauses access to your site, affects your analytics, including third-party analytics tools, and may affect API traffic. There is no documented time limit; the practical rule is to turn it on for the attack and off once traffic is back to normal.

How to turn it on or off:

1. Whole zone: open your domain's Overview page and use the Under Attack Mode toggle in the Quick Actions sidebar. In the new security dashboard it is the Security Level setting on the Settings page. Turn it off with the same switch.
2. One part of the site: create a configuration rule (Rules, Configuration Rules) that matches a path such as /admin and sets "I'm Under Attack" to on. The same type of rule can turn it off for your API while the rest of the zone stays protected.
3. Specific countries, ASNs or IP ranges: Cloudflare points to IP Access rules.

Before you need it, preview the page your visitors will see: Custom Pages, the Managed Challenge / I'm Under Attack Mode entry, View default.

What about crawlers? When Cloudflare introduced the mode in 2012, it said the checks were designed not to block search engine crawlers. The current documentation does not describe how it treats verified bots. Treat that as unconfirmed: keep the mode short and check crawler responses while it runs.

How challenges can hurt SEO

Do not count on a search crawler getting past a challenge. A challenged crawler receives a 403 HTML page instead of your content. Google says it treats all 4xx codes except 429 the same: the content does not exist. URLs that keep returning 4xx are not indexed, and pages already indexed are removed. Google also says not to use 403 to slow down crawling.

So every challenge or block rule needs an exception for verified bots. Cloudflare's field cf.client.bot is true when a request comes from a known good bot or crawler, and Cloudflare's own example of a Managed Challenge rule adds not cf.client.bot to the expression. Verified bots are also grouped by purpose, and Search Engine Crawler is one of those categories (available in rules as cf.verified_bot_category).

In the traffic reports we have prepared, the usual damage came from hand-written rules that challenge or block a country, a cloud network or a user agent pattern and catch Google's or Bing's crawlers by accident. After any change:

1. Open Analytics, then the Events tab (Security Events), and add a filter for the user agent of Googlebot or Bingbot. Any challenge or block action there needs a fix.
2. Confirm the requests are real with Verify Googlebot. User agents are easy to fake, so a "Googlebot" that was blocked may be a scraper.
3. Check the crawl stats report in Search Console a few days later.

Ready rules with crawlers excluded

Each rule below uses Managed Challenge and keeps verified bots out of scope. Free plans have 5 custom rules, so pick the ones your traffic actually needs. Compare limits in which Cloudflare plan you need.

Challenge the WordPress login page:

(http.request.uri.path eq "/wp-login.php" and not cf.client.bot)

Challenge countries you do not serve (replace the codes with the ones from your own logs):

(ip.src.country in {"CN" "SG"} and not cf.client.bot)

Challenge cloud networks that real shoppers rarely use, such as DigitalOcean (AS14061) and Amazon (AS16509):

(ip.src.asnum in {14061 16509} and not cf.client.bot)

Use Block only for sources you are certain about, such as a single abusive IP; see how to block an IP in Cloudflare. Before writing any rule, a free bot traffic report shows which networks, user agents and hours actually cause the load, so you challenge the right thing.

Turnstile: the challenge for forms

Turnstile is Cloudflare's CAPTCHA alternative, built on the same technology as challenge pages. The difference: a WAF challenge replaces the whole page, while Turnstile is a widget you place inside a form, such as signup, contact or checkout. It works on any site, even one that does not send traffic through Cloudflare.

It has three modes: managed (recommended, shows a checkbox only when needed), non-interactive and invisible. Your server must validate each token with the siteverify API; a token is valid for 300 seconds and can be checked once. Turnstile can also issue a pre-clearance cookie, so visitors who pass the widget are not challenged again by your WAF rules on API calls.

FAQ

What is the difference between Managed Challenge and JS Challenge?

JS Challenge always runs the same non-interactive script check. Managed Challenge lets Cloudflare pick the check per request, so most people pass without doing anything and only suspicious visitors may have to click. Cloudflare recommends Managed Challenge for most rules.

Does Cloudflare Under Attack mode work with an API?

No. API clients cannot pass the check page, and Cloudflare warns the mode may affect API traffic. Use a configuration rule to turn Under Attack mode off for your API path or hostname.

Why do I keep seeing the Cloudflare challenge page?

Common causes are JavaScript turned off, extensions or ad blockers that block the challenge script, a VPN or network that changes your IP, or an outdated browser. Try a private window, another browser or another network.

Do challenges block Googlebot?

They can. A challenged crawler gets a 403 page, and Google drops URLs that keep returning 4xx. Add not cf.client.bot to every challenge rule and check Security Events for crawler user agents after each change.

• Block or allow an IP in Cloudflare
• Block an IP address
• Block bots with robots.txt