Cloudflare Error 1020: Access Denied Explained & Fixed

You click a link, and instead of the page you wanted, Cloudflare hands you a blunt message: Error 1020: Access Denied. It's one of the more frustrating errors because it doesn't tell you much. The short version: your request tripped a firewall rule that the site's administrator configured through Cloudflare's Web Application Firewall (WAF).

That rule could be doing any number of things: restricting a particular path, limiting traffic from certain regions, throttling rapid-fire requests, or filtering IP ranges. This guide covers both sides of the fence, what to do if you run the site and are seeing legitimate visitors blocked, and what to check as a user or developer who has a genuine reason to reach a page or gather public data.

What Error 1020 Actually Means

Cloudflare sits between visitors and the origin server as a reverse proxy. Before a request ever reaches the website, Cloudflare evaluates it against the rules the site owner has set up. Error 1020 is what you get when a custom WAF rule (a "firewall rule") matches your request and its action is set to Block.

The key detail: 1020 is almost always a custom, admin-defined rule, not a default Cloudflare behavior. That distinguishes it from managed challenges or rate-limit responses. Something specific about your request, its path, headers, country, IP reputation, or request rate, matched a condition the administrator wrote. If you see other 10xx codes, our roundup of simple fixes for proxy error codes and the deep dive on Cloudflare Error 1006 cover the neighboring cases.

Fixing Error 1020 as the Site Administrator

If you control the website, this is the easy path, because you own the rule that's firing. Start in your Cloudflare dashboard.

Open the Security section and find Events (or Security Analytics on newer dashboards). This log shows recent security actions, including which requests were blocked and, crucially, which rule blocked them. Filter for the 1020 events and read the matched rule. Nine times out of ten, the fix is obvious once you see what condition triggered.

From there you have a few sensible options:

• The rule is too broad. Maybe you blocked an entire country or ASN and it's catching real customers. Narrow the scope, or switch the action from Block to Managed Challenge so legitimate visitors can prove they're human instead of being denied outright.

• The rule is redundant. If it duplicates protection you already get from Cloudflare's managed rulesets, consider disabling it.

• The rule is fine but the threshold is aggressive. For rate-based rules, raise the request threshold or widen the time window so bursts of normal traffic don't get caught.

Avoid the temptation to simply delete every rule that causes friction. A better habit is to test changes on a subset of traffic first and watch the Events log to confirm real visitors are getting through while unwanted traffic is still filtered.

Resolving Error 1020 as a User or Developer

If you don't run the site, you can't touch its firewall settings, so the goal shifts to figuring out whether the block is aimed at you specifically or at the traffic pattern you're producing. Work through these checks in order.

Confirm the scope of the block

Try loading a few different pages on the same domain. If only one URL returns 1020 but the homepage loads fine, the rule is protecting that specific resource, an admin panel, a checkout endpoint, a private document, and you likely aren't meant to access it directly. If the entire site returns 1020, the block is tied to your connection: your IP's reputation, your location, or a network you're routing through.

Check your VPN or network

Consumer VPN services recycle a small pool of IP addresses across thousands of users. When one user on a shared IP behaves badly, site owners often block the whole range, and everyone else on that IP inherits the ban. Disconnecting the VPN and retrying on your normal home connection is the fastest way to test whether that's the cause.

If you have a legitimate reason to route through a different IP, say you're testing how your own site renders from another country, or collecting publicly available data at scale, residential IP addresses behave far more like ordinary home users than recycled VPN endpoints. Evomi's residential proxies are sourced from real, consenting connections and are ethically obtained, which keeps your access legitimate and your traffic representative of genuine users. There's a free trial if you want to test against a specific site before committing.

Rotate to a different proxy IP

Even on a good proxy pool, an individual IP can carry a poor reputation inherited from prior use. If you're on a sticky session (holding one IP for a while), request a fresh IP and try again. Before you blame the site, confirm the proxy itself is healthy and geolocated where you expect using geo.evomi.com and the free proxy tester.

If you're already rotating IPs and still get 1020 consistently, the issue isn't the specific address, it's the rule condition. Re-read step one: you may be requesting a path that's simply off-limits, or your requests may be arriving faster than the site's rate rule permits.

Slow down and respect rate limits

A very common 1020 trigger for developers is request velocity. If a script fires hundreds of requests a second at a domain, a rate-based firewall rule will block it, and rightly so. For legitimate data collection on public pages, add delays between requests, respect the site's robots.txt, and check whether the site offers an official API before scraping HTML. Our guide on fixing failed Python requests walks through sensible retry and backoff strategies that keep your traffic polite.

Send complete, honest request headers

Bare HTTP clients often omit headers a normal browser always sends. A request with no User-Agent, no Accept header, and no Accept-Language looks malformed and can match a firewall rule. The fix isn't to disguise anything, it's to send a truthful, complete set of headers that accurately describes your client, exactly as a real browser would. You can see what your current setup transmits at check.evomi.com. For a primer on header-related issues, the most common HTTP proxy errors article is a good companion.

Use a full browser for JavaScript-heavy sites

Some pages genuinely require a real browser to load, they set cookies, run challenges, or render content client-side that a plain HTTP request never sees. If a simple script keeps failing where a browser succeeds, switch to browser automation with Playwright or Puppeteer. Evomi's managed Scraping Browser is a cloud headless Chromium endpoint (wss://browser.evomi.com) that's Playwright- and Puppeteer-compatible, so you get a real browser environment for accessing public content without maintaining your own fleet.

A Quick Reference for 1020 Causes

Wrapping Up

Cloudflare Error 1020 is less mysterious than it looks. It's a custom firewall rule doing its job. If you run the site, the Events log tells you exactly which rule fired and lets you tune it so real visitors aren't caught in the crossfire. If you're a user or developer with a legitimate reason to reach a page, work through the checklist, scope, network, IP health, request rate, and headers, and you'll usually find the cause. For related Cloudflare codes, see our guides on Error 1015 and Error 1003.