What Error 1020 Means#
Error 1020 means access denied by a firewall rule. Someone who runs the website wrote a rule about who may reach it, your request matched it, and Cloudflare refused you on the owner's behalf. Cloudflare's error 1020 reference states it in one line: access is denied by a Cloudflare firewall rule, because a client or browser is blocked by a customer's rules. It is not a Cloudflare policy, not a browser fault, and not a defect you can repair from your side.
Underneath the branded page it is an ordinary HTTP 403. Cloudflare's rules language actions reference gives the block action's status as 403 for most security features, or 429 for rate limiting rules. That is why your network panel reports 403 while the page says 1020: one is the status code, the other is the reason.
Where the decision happened matters more. The refusal is made at the edge, in the data center that answered you, so the site's own servers are never contacted. The lab behind this article models that on loopback, seven checks passing on Node v24.14.0: when the rule matched, the edge produced the refusal itself and never reached the origin.
One consequence follows. When you tell the site's support that their pages refuse you, their application logs show no trace of your visit, because your request never arrived. They are not brushing you off. The record exists in the edge's security event log, and reaching it takes one piece of information already on your screen.
Client
browser or CLI
DNS
name → address
TCP
SYN / SYN-ACK
TLS
handshake + cert
Origin
firewall access rule matched
Hops after the highlighted failure never run — everything downstream is ruled out before you start.
A site-owner rule at Cloudflare's edge denied the request before the origin saw it. That is a decision, not a fault — respect it.
Read the Block Page Before You Change Anything#
Before you change any settings, reproduce the refusal outside the browser. Run curl -sS -i against the URL that refused you and read the status line, the cf-ray header, and the body. If curl is refused exactly as your browser was, the rule is keyed to your network rather than your browser, since curl shares little with Chrome beyond the address it comes from. Here is the refusal as the lab's edge returned it to curl, transport headers omitted:
curl -sS -i http://127.0.0.1:8123/gated
HTTP/1.1 403 Forbidden
Content-Type: text/html
<html><body>Error 1020 (model): access denied by an edge rule</body></html>Two recorded details do the diagnostic work. There is no Retry-After header on that response, and a real 1020 carries none either, because time is not what the rule matched on. The refusal was also identical on every attempt, so reloading changes nothing, and code that retries it as a transient failure is waiting out a window that does not exist.
The number itself is a diagnosis, and its neighbors ask for opposite reactions.
| What you see | Who decided | What it means | What resolves it |
|---|---|---|---|
| Error 1020 | The owner's access rule, at the edge | You matched criteria the owner chose to refuse | The Ray ID, sent to the site's support |
| Error 1015 | The owner's rate limiting rule | You sent requests faster than the threshold | Wait out the window, then return slower |
| Error 522 | Nobody. The edge could not reach the origin | The origin is down or too slow to answer | Only the owner can fix it |
| A plain 403 page | The application, behind the edge | The server understood the request and refused to process it | Fix the permissions, path, or credentials |
The lab makes that split mechanical. Failing the access rule's criterion produced the refusal while satisfying it returned 200, so the outcome depended on the visitor. With the origin unreachable, the edge answered 522 for everyone, including a visitor who satisfied the rule. A 1020 is about who you are. A 522 is about the site.
Why Your Request Matched, Ranked by Likelihood#
Rules match on attributes of a request: the address, the country inferred from it, the network that owns the range, headers, path, method. A handful account for nearly every 1020, in rough order of likelihood.
A VPN or hosting network address. Consumer VPN exits and cloud servers sit in ranges that are easy to identify in bulk as non-residential, and many owners refuse them wholesale. The VPN and proxy comparison explains why a device-level VPN sends every request from one shared exit, which is all the rule sees.
A country or region rule. Plenty of sites serve one market or license content regionally, and the country is inferred from your address. This is why a site works at home and refuses you on a business trip. The page never says it does not serve your region. It says 1020.
An address range with a history. Residential and mobile addresses are recycled constantly, and rules are often written against whole ranges rather than single addresses, so you can inherit a block earned by whoever held that address last month. This is the accurate version of the forum answer that your range has seen abuse.
A request shape that looks automated. Extensions that rewrite headers, HTTP libraries sending their default user agent, and browsers that do not present a normal handshake all give a rule something to match.
A shared corporate or campus exit. Hundreds of people leave through one address, and one of them, or a security appliance opening links on their behalf, earns the whole building a rule.
A rule broader than its author intended. More common than owners admit: a narrow intent expressed as a country block, or a rule added during an incident and never removed. Rules written to stop one attack outlive it by years.
You cannot tell which applies from the outside. Only the firewall's own event log knows.
The Ray ID Is What Actually Resolves a 1020#
Every request that passes through Cloudflare is stamped with a Ray ID, as the Cloudflare Ray ID reference describes. It appears near the bottom of the block page and in the cf-ray response header: a hexadecimal string, a dash, then a three-letter code for the data center that handled you. It works in one direction. You hand it to the site, and the site looks up why you were refused.
Cloudflare's own instructions to owners explain why nothing you do locally can substitute. The owner takes the screenshot from the customer, searches the Security Events log for the Ray ID or the client IP address from the error message, converting the error's UTC timestamp to their local time zone, then assesses the cause and either updates the rule or allows that address. The log names the rule that fired and the action it took. Clearing caches and reinstalling browsers cannot produce that answer: the reason lives in the owner's configuration and nowhere else.
So screenshot the whole block page, which is what Cloudflare tells blocked visitors to send, and write to the site's support with four things: the Ray ID, the date and time with your time zone, the exact URL, and the public address the page displayed. If you are a paying customer, say so: a legitimate user tripping a rule during ordinary use is precisely the report an owner wants.
One sourced caveat separates a ticket that resolves from one that stalls: Cloudflare notes that Ray IDs are not guaranteed to be unique for every request, so the timestamp and URL beside it make the lookup unambiguous. Capture all four while the block page is still in front of you.
Self-Checks That Identify the Trigger#
Each check below identifies which attribute the rule matched, so your report says something useful. None is an attempt to make a refused request succeed.
First, if a VPN or a system-wide proxy is switched on, turn it off and load the page again. This is the highest-yield check, because the largest category of 1020 rules targets VPN and hosting ranges. If the page loads, the rule targets that network. If it refuses you both times, the cause is your own address, your region, or your request. The proxy and firewall checklist shows where a forgotten system proxy hides.
Second, try one other network you already control, most easily your phone on mobile data with Wi-Fi off. Refused on both means the rule is not keyed to a single address. Refused on one confirms it is address-based.
Third, check what address the site actually sees with the browser IP diagnostic. Fourth, retry in a clean browser profile with extensions disabled: if the page loads, an extension was altering your requests. Fifth, clear cookies, but only if the block began mid-session or affects one account. An address or country rule does not read your cookie jar.
There is a line worth stating once, because the most upvoted advice on this topic crosses it. Turning a VPN or proxy off to learn whether it is the trigger is diagnosis, and we recommend it. Reconnecting through a different exit, account, or fingerprint until the same request stops matching is a different act: the rule refused you deliberately, and presenting a new identity so it stops applying works around the owner's access policy instead of resolving anything. Databay sells proxy infrastructure and this page still says so; the compliance guide sets out where authorized use ends. The route back is the site's support with your Ray ID.
Error 1020 on Android, Windows 11, and Managed Networks#
No operating system produces this error, so nothing on your device is broken. The platform matters only because the intermediary that got you matched sits in a different place on each.
On Android, an app showing 1020 inside its own web view is displaying the same block a browser would. Look for a device-wide VPN, indicated by the key icon in the status bar, then for ad-blocking apps, which commonly run as a local VPN service and send your traffic out through their own exit, then for a Private DNS entry. Turn off what you control and retry. Carriers also place many subscribers behind a small pool of public addresses, so a phone can inherit a rule aimed at someone else.
On Windows 11, open Settings, then Network and internet, then Proxy, and look for a manual proxy or an automatic setup script left behind by software you removed. Then check for a VPN client and for security agents that route traffic through an inspection service. Chromium browsers use the system proxy configuration, so a stale entry refuses identically in Chrome and Edge while Firefox, which keeps its own settings, is unaffected. That asymmetry identifies the cause without changing anything.
On a school, office, or hotel network, the exit address is not yours and the rule may have nothing to do with your behavior. Two policies apply and neither is yours to set: the network belongs to its administrator, the rule belongs to the site. Report the Ray ID to the site, and if the block follows your organization's address everywhere, raise it with whoever runs the network.
When Your Own Site Returns Error 1020#
From the owner's chair, a 1020 report means a rule you deployed matched a customer. The repair is scoping, not deletion. Country rules top the causes, because country is inferred from an address and traveling customers, carriers that egress abroad, and VPN users all break that inference. Next come rules against hosting ranges, which catch uptime monitors, messaging-app link previews, and partner integrations. Then rules added during an incident and never removed. Give every rule you write under pressure an owner and an expiry date.
Know which layer refused before you tune anything. Managed rulesets are Cloudflare's own pre-configured rules, maintained by their security team against known exploit patterns. A custom rule is one you or a predecessor wrote, evaluated exactly as written. Custom rules run in an earlier phase than managed rules, so a terminal action from your own rule means the managed ruleset was never reached. Teams lose days tuning a managed ruleset for a block their own forgotten custom rule produced.
Run the same lookup described above from your side: find the customer's Ray ID in your security events and read the matched rule, the matched field, and the action. Fix the rule's scope rather than adding a one-off exception, because the next hundred people the same rule matches will not write to you. They will leave, and you will never learn why.
Two habits prevent most of these tickets. Deploy new rules in log mode for a day and read what they would have blocked before promoting them. And prefer a challenge to an outright block for ambiguous traffic: a challenge lets a real browser prove itself, while a block ends the request for everyone the expression matches, including the customers you meant to keep. Certainty deserves a block. Suspicion deserves a challenge.
