Cloudflare Error 1020 Access Denied: What Triggers It and How to Get Past It

Cloudflare's numbered errors are more useful than a bare 403 because each one names the subsystem that acted. 1020 specifically means a WAF custom rule with a block action matched the request. Somebody deliberately wrote the condition that caught you, which is good news: conditions are finite and testable.

Which Cloudflare code you actually have

Getting this right saves hours. A 1015 will clear on its own if you pace properly, as covered in HTTP 429. A 1020 will not clear no matter how long you wait, because nothing about it is time-based.

What custom rules typically match

Cloudflare exposes a long list of request fields to rule authors. In practice a handful account for almost every 1020 people encounter.

Diagnosing it as a visitor

If you are a legitimate user of the site, 1020 usually means something about your connection matched a rule aimed at somebody else.

1. 1Turn off the VPN. Consumer VPN ranges are the single most commonly blocked ASNs.
2. 2Try mobile data. A different network with a different ASN answers the question in ten seconds.
3. 3Disable extensions that modify requests, then reload.
4. 4Clear the site's cookies. A stale cf_clearance can produce odd behaviour after a rule change.
5. 5Note the Ray ID and email the site. The owner can look it up and see the exact rule that fired — you cannot.

Diagnosing it as an operator

For automated traffic, the goal is to identify the matched field by changing exactly one variable at a time and recording the result.

• Country — same request, exit in a different country. A clean success points straight at a geo rule.
• ASN — same country, residential exit instead of datacenter. This flips more 1020s than anything else.
• Client — the same URL in a real browser on the same connection. Success means the address is fine and the client is not.
• Path — a different, plainly public URL on the same host. Success means the rule is scoped to the path you wanted.
• Method — a GET where you were sending POST.

Record the Ray ID for every failure alongside the exit IP, country and timestamp. When the same rule fires across a hundred requests, the pattern in that table is the answer, and reconstructing it afterwards from logs that only stored 403 is impossible.

What does not work

Three approaches come up constantly and are worth ruling out before you spend time on them.

• Waiting. A custom rule has no cooldown. It will block the same request next week.
• Retrying harder. The rule is deterministic; the hundredth attempt matches exactly as the first did.
• Solving a CAPTCHA. A block action never presents a challenge. If you are seeing a challenge, you have a managed challenge rule, not 1020.

If you own the site

From the other side, 1020 is your own rule doing its job on the wrong traffic. Open Security Events, filter to blocked requests, and read what actually matched — the field and value are shown per event.

1. 1Sort blocked events by rule to find which one is over-firing.
2. 2Check whether real customers are in the sample. Country rules catch travelling users constantly.
3. 3Narrow the condition rather than deleting the rule.
4. 4Move borderline rules from block to managed challenge, which lets humans through and still stops most automation.
5. 5Add an allowlist for your own monitoring, uptime checks and payment webhooks before they page you at 3am.

Error 1020 is ultimately a communication problem: a rule expressing an intention, meeting a request that did not know the intention existed. Whichever side of it you are on, the fix comes from reading the actual match rather than guessing at the policy.