Cloudflare IP Ban Check: Diagnose 1020, 1015 and Challenge Loops

Read the code before calling it a blacklist

Cloudflare’s 1020 documentation attributes that error to a firewall rule applied by the website’s owner. Its separate 1006-family documentation covers errors that explicitly describe an address being denied. Neither page defines a public, universal “Cloudflare blacklist” that a third-party checker can clear.

Treat a result on one hostname as evidence about that request to that hostname. Another site can use different rules, accounts, application checks and security products. Conversely, successful access to one Cloudflare-protected site does not prove that every other site will accept the same visitor.

If you do not see a Cloudflare-specific code, retain the HTTP status and response text. A generic 403 can originate from the application or another layer. Our IP-ban diagnosis guide covers that wider decision tree.

Create a support record that can be matched to a request

Record the exact URL, time with time zone, visible code and Ray ID. Include the browser version and whether the problem happens while signed in. Give the public IP privately to the site’s support team if needed; avoid putting session cookies or authorization headers in a public report.

A Cloudflare Ray ID helps the owner correlate traffic with security events. It is not an account identifier, and Cloudflare warns that it is not guaranteed to be unique for every request. Include time and hostname with it. Some event views are sampled, so an empty search is not conclusive evidence that the request never reached Cloudflare.

A compact report can look like this:

Affected URL: https://example.com/account
Observed time: 2026-10-11 10:15 UTC
Visible error: 1020
Ray ID: copied from the error page
Browser: name and version
Result: public homepage works; account page fails
Recent change: browser update; no other settings changed

This is an illustrative format, not a real incident. Keep the report limited to what you observed. “The account page failed twice at this time” is more useful than a claim that the entire carrier is blacklisted.

For visitors: test the browser and connection carefully

For an ordinary browsing session, use an up-to-date supported browser with JavaScript enabled. Test a clean browser profile to isolate an extension or customized setting. If policy permits, compare one trusted network while leaving the rest of the setup unchanged. These are diagnostic comparisons, not assurances that the website will grant access.

Cloudflare’s challenge troubleshooting guide distinguishes browser and network failures from a block decision. It also documents two misleading developer-console symptoms: a Private Access Token request can return 401 without the overall challenge failing, and some challenge-related DNS test failures are expected. Do not diagnose the incident from a single red console line.

If the only failure is in an app’s embedded browser, try the site in a normal supported browser and report the difference to the app or site operator. A WebView and a full browser can expose different capabilities. Keep the normal session intact until you know whether the alternate test helped.

For an explicit deny page, contact the website’s support team with your record. Cloudflare infrastructure does not make an unrelated proxy seller the owner of the site’s access policy.

For 1015: stop the retry loop

The 1015 reference identifies site-configured rate limiting and tells visitors to avoid rapid repeated attempts. There is no universal wait time supplied by that documentation. Follow any timer or retry guidance the actual service provides, and ask its operator if normal use is still being rejected.

A dashboard auto-refresh, duplicate scheduled task or aggressive client retry can create more traffic than the person using the page expects. For a job you control, pause it and inspect the number of requests, concurrency and retry behavior. Changing addresses without fixing the request pattern leaves the underlying operational problem unresolved.

Distinguish the failure of a browser page from a rate limit on an API integration. Use the API’s documented limits and authenticated access path for that integration. A browser challenge response is not the JSON payload your application expected, even if a parser can read its body as text.

Keep one connection through a challenge

Cloudflare’s challenge mechanism documentation says a Managed Challenge cannot be completed from a different IP than the one that received it. Rotation between those steps can therefore cause a loop. A network switch, VPN reconnect or changing proxy session may be relevant evidence; it is not proof that the new address has poor reputation.

For a permitted browsing workflow, keep the selected route stable while investigating. The browser proxy guide helps identify which browser process uses the endpoint. If the browser runs in a hosted service, check that session’s configuration; changing your laptop’s proxy does not change the remote browser’s exit address.

Do not export someone else’s clearance cookies or buy a purported universal challenge pass. Such a credential does not give your application permission to access the target, and a copied token is not a diagnosis of the request that failed.

For site owners: inspect the matched rule and test a narrow correction

Find the affected request in your site’s security events using its time, hostname, Ray ID and client address. Review the action and matched policy before editing rules. Check whether the expected legitimate workflow is a browser page, an API request, a health check or another integration. A rule suitable for one may interrupt another.

Cloudflare’s 1020 page still refers to its deprecated Firewall Rules product. Treat that as the error’s documented context, not a reason to recreate an obsolete configuration. Use the controls available for the active rule in your own account, and follow that product’s current documentation.

When correcting a false positive, scope the exception to the verified requirement and preserve the original configuration so you can reverse the change. Do not disable every security control because one customer reported a block. Validate the intended request and a request that should remain blocked.

For an authorized AI or data integration, agree an authenticated API or another documented access method with its operator. Record that agreement alongside request limits and contact details. Our AI crawler checker can help inspect published crawler directives; it cannot reveal private WAF rules or grant access.

AI browser agents are a separate compatibility case

Cloudflare’s supported-browser documentation, updated in August 2026, explicitly says automated browsers and frameworks such as Playwright, Selenium, Puppeteer and Cypress are unsupported for solving production challenges. A model controlling the browser does not remove that limitation.

For testing a Turnstile integration you own, the documentation directs automated tests to test keys. A test-key success establishes behavior in that test setup; it is not a benchmark of production challenge completion. Keep test credentials out of the production configuration.

For an AI workflow against another site, detect the denied or challenged response, stop the task and surface it to the operator. Do not let an agent repeatedly click, submit forms or rotate endpoints while reporting success. Use the Browser Use integration guide for connection setup and this guide for interpreting an access failure. Record proxy connectivity and destination access as separate test results.

Our JA4 checker can record a TLS observation for a request to Coronium. It cannot expose the affected site’s private bot score or explain its decision by itself.

Frequently asked questions