Cloudflare Under Attack Mode: What It Means for Automated Clients

I’m Under Attack mode is a Cloudflare setting that puts an interstitial challenge page in front of every visitor to a zone. Cloudflare says “When you enable Under Attack mode, Cloudflare will present a Managed Challenge page”, that the check “determines whether to block or allow a visitor within five seconds”, and that the mode is “designed to be used as one of the last resorts when a zone is under attack”. For an automated client it means every request gets a challenge page (HTTP 403 with cf-mitigated: challenge) until it holds a valid cf_clearance cookie, and clients that run no JavaScript cannot get one.

This article explains what changes when a site turns the mode on, how to recognise it, and what a scraper, a monitor or an API client should do, as Cloudflare documented it on 1 October 2026.

What the mode does

• Who is challenged: every visitor to the zone, unless the owner limits it: “To enable or disable Under Attack mode for your API or any other part of your domain, create a configuration rule.”
• What they see: an interstitial page, which Cloudflare’s reference names as the Checking your browser before accessing... challenge and its security-level page as a Managed Challenge page.
• How long a pass lasts: “After passing the challenge, the visitor does not observe another challenge until the duration configured in Challenge Passage.”
• What it needs: JavaScript. Cloudflare notes that “Since the Under Attack mode requires your browser to support JavaScript to display and pass the interstitial page, it is expected to observe impact on third party analytics tools.”
• Default: “Under Attack mode is turned off by default for your zone.”

Under Attack mode now lives in the Security Level setting: “In the new security dashboard, the Cloudflare API, and in Terraform, use security level to turn Under Attack mode on or off.” The old threat-score levels are gone (“Now, the threat score is always 0 (zero).”), so for current zones a security-level change is, in practice, this mode going on or off.

How to recognise it

From the client side, an Under Attack page is a challenge page like any other:

• the status is 403;
• the header cf-mitigated is challenge;
• the content type is text/html, even for a request that asked for JSON.

What sets it apart is scope and timing: suddenly every URL of a site challenges you, JSON endpoints and images included, where yesterday none did. A WAF rule usually covers some paths or some visitors; Under Attack mode usually covers everything. Site owners can see the difference in their rules: Cloudflare’s field cf.response.error_type reports iuam for these responses, next to managed_challenge, legacy_challenge and country_challenge.

This check tells you whether a whole site is behind a challenge right now, by asking a page and a JSON endpoint:

import requests

URLS = ["https://shop.example.com/", "https://shop.example.com/api/status"]

challenged = []
for url in URLS:
    response = requests.get(url, timeout=30, headers={"Accept": "application/json"})
    if response.headers.get("cf-mitigated") == "challenge":
        challenged.append(url)
    print(response.status_code, response.headers.get("cf-mitigated", "-"), url)

if len(challenged) == len(URLS):
    print("Every URL is challenged: Under Attack mode or a zone-wide rule is likely on.")

What an automated client should do

1. Slow down first. The mode is a DDoS response. The site is under load, and more requests make it worse. Back off, lower your concurrency, and check again later: the mode is meant to be temporary.
2. Don’t hammer the challenge. Retrying the same request in a loop only produces more challenge pages. A client without JavaScript will never pass, however often it tries.
3. If you must keep going and are allowed to: pass the challenge once per session, in a browser or through a service that runs it, then reuse the cf_clearance cookie for every request until it expires, from the same IP address and with the same user agent. The cf_clearance cookie explained covers how.
4. If you run the site: use a configuration rule to keep the mode off your API paths while it protects your pages, as Cloudflare suggests, and give partners who call your API another way in rather than asking them to pass a browser challenge.

For step 3, ZeroCaptcha’s challenge task passes the page through your own proxy and returns the cf_clearance cookie with the user agent it is bound to. It is a paid task like any other, so solve once per session and reuse the cookie, rather than once per request. See Cloudflare WAF and 5-second challenges and the Cloudflare WAF and 5-second challenge solver. Only automate sites you are allowed to: see responsible captcha automation.

Under Attack mode and the other challenges

The Cloudflare challenge types article compares the challenge actions, and Cloudflare’s challenge platform explained covers what the page loads. If a challenge keeps returning after you pass it, see the challenge loop article.

Sources

• Cloudflare: Under Attack mode (checked 1 October 2026).
• Cloudflare WAF: security level (checked 1 October 2026).
• Cloudflare challenges: detect a challenge response (checked 1 October 2026).
• Cloudflare challenges: additional configuration, for cf.response.error_type (checked 1 October 2026).
• Cloudflare: Error 403 (checked 1 October 2026).

The team that builds and runs the ZeroCaptcha API. Articles are drafted with AI tools, then checked against the API's code and the primary sources each one cites.