Cloudflare Error 1020 is an access-denied response associated with a Cloudflare firewall rule. The site owner should investigate the firewall rule that blocked the request, while a visitor should report the error to the owner. The error page alone does not show that the visitor is malicious or that the website's origin server is broken.

A fix is appropriate when a rule denies traffic that the site intends to accept. Blocking a legitimate request by mistake is called a false positive. Adjust the rule so that those requests can pass while the traffic it is meant to stop remains blocked.

Capture the Blocked Request

Ask the affected visitor for the hostname and path, the approximate time with its time zone, and a screenshot of the 1020 page. Include the Ray ID shown on that page when available. If an IP address is needed to locate the event, share it only with the people investigating the issue.

Check whether the issue applies to a single page, a login flow, an API endpoint, or the whole hostname. Note whether the same user receives the error consistently or only for a particular action. Do not ask the visitor to send passwords, session cookies, or entire request bodies. Those values are unnecessary for the initial event lookup.

Cloudflare assigns Ray IDs to requests, but the IDs are not guaranteed to be unique. Use the Ray ID together with the request's time and URL. Match the timestamp to the time zone used in the dashboard: for example, 14:00 UTC is 17:00 in UTC+03:00. Keep the original timestamp alongside the converted value so another investigator can check the same interval.

Find the Matching Security Event

Select the correct site in the Cloudflare dashboard and open Security, then Analytics, then the Events tab. Filter by the reported Ray ID or client IP and time window. Expand the candidate event and compare its hostname, path, and time with the report. Record the action and the responsible security feature or rule.

Security Events can show sampled data, so a missing event is not proof that no block occurred. Reduce the search interval and confirm the dashboard's time zone and selected filters. If the event is still missing, check other available request logs or repeat the blocked request under the same conditions before deciding which rule to edit.

The older Firewall Rules product is associated with Error 1020; current configurations can also include WAF custom rules and other security features. WAF means web application firewall. These features have different actions and error responses, so a generic HTTP 403 response is not enough to identify Error 1020. Use the actual code and event details to decide which policy needs review.

Review the Rule That Blocked the Request

Read the rule expression, action, scope, and order in the context of the matched request. Determine whether the visitor should have been allowed. A condition based on a visitor's country, IP address, requested path, or user agent can be too broad and block legitimate traffic. Compare examples of legitimate and unwanted requests before changing the condition, especially around login and administrative endpoints.

Check whether the rule was newly added or recently edited. Also review preceding access decisions and overlapping rules. A Block action stops evaluation of later rules, so an exception below that block cannot undo it. Moving or editing a rule without checking this order can leave the original denial unchanged.

For example, suppose a rule is intended to protect an administration area but tests whether the path contains /admin. That condition also matches /admin-help, which might be a public help page. If only /admin and paths beneath it should be restricted, match /admin exactly or a path beginning with /admin/, rather than every path containing /admin. Confirm that this boundary fits the actual application before using it.

If the request should remain denied, document the reason and give the visitor an appropriate explanation. A correct security block is not a configuration defect. If the request is legitimate, identify the narrowest condition that distinguishes it from the traffic the rule is meant to stop.

Adjust the Rule or Its Exception

For a custom rule, open the matched rule on the Security rules page and inspect its conditions and action. Correct the condition responsible for the false positive, then save and deploy the intended change. For another security feature, use that feature's controls rather than creating an unrelated custom rule and assuming it overrides the block.

If a Skip exception is appropriate, limit its matching conditions and select only the protections it needs to skip. A broad IP Access Allow rule can bypass custom rules, rate limiting, and managed rules, so it is not equivalent to a narrowly configured Skip rule. Review the actual options before applying either approach.

Do not disable the whole firewall or remove unrelated controls simply to clear the 1020 page. If a security team or hosting operator manages these rules, send the event evidence to that team for review. Preserve the original condition and the reason for the change so the previous configuration can be restored if the change has an unwanted effect.

Retest Access and Check That Blocking Still Works

Have the affected user repeat the intended request after the authorized change, using the same relevant client and request conditions. Confirm that the page or operation now works. Changing networks or using a different path may avoid the original condition without proving that the rule was corrected.

Compare the new request with available logs, but do not require a new Security Events row for every successful request. That view covers requests acted on or flagged by security features. IP Access Allow rules and Skip rules with logging disabled can also keep requests out of Security Events. Check the saved rule conditions as well as the page's response.

Check that requests which should still be denied remain blocked. If the original operation is still denied, record its new Ray ID and time before investigating the next matching rule. If the change allows more traffic than intended, restore the previous configuration and revise the exception before trying again.