Cloudflare error 1020 reports a request blocked by a security feature configured by the site owner and is returned with HTTP status 403. A site can work for one person while blocking another request, so investigate the failed request using its Ray ID, address and time. Visitors can report that evidence; site owners can match it to Security Events and review the rule’s intended scope.
Guide reviewed: October 20, 2026. Interface labels may vary by version, account and device.
Cloudflare’s current documentation distinguishes this response from WAF custom-rule and managed-rule block pages. It gives API Shield schema validation and JWT validation as examples of features that can return 1020. Identify the actual feature in the event instead of assuming every security block follows the same workflow.
Match the blocked request to its security rule
| Your situation | Useful action | Evidence to keep |
|---|---|---|
| You are a visitor | Contact the website owner privately | URL, error screenshot, Ray ID and failure time |
| You own the site | Find the matching security event | Rule, action and request context |
| No event matches | Check account, time range and time zone | Original evidence rather than unrelated setting changes |
| A legitimate workflow is blocked | Review the specific condition with its maintainer | Expected behavior and original rule configuration |
If you are a visitor, send the owner the error details
A visitor generally cannot change the site’s Cloudflare rules. Keep a screenshot showing the error and Ray ID, along with the page address and the time it happened. Send those details privately to the website owner through an available contact method.
For example, saying that the contact page was blocked at a particular time gives the owner something to search for. A report that the whole site is broken is less precise when the block may depend on a request path, network, or matching rule.
Avoid repeatedly submitting a form if you are unsure whether a previous attempt succeeded. If the blocked action involved an order or another important submission, ask the site owner to confirm its status rather than treating a different browser as proof that the earlier request failed completely.
If you own the site, locate the security event
Search the actual failure. Use the Ray ID where available and include the correct time window. Record whether the screenshot timestamp and dashboard use UTC or local time. Once the matching event is found, read the condition and action before deciding whether the block is intentional or a false match.
Cloudflare recommends searching Security Events using the Ray ID or the client IP associated with the error. Pay attention to the time zone when matching the request time; its documentation specifically notes converting the error’s UTC timestamp to the local time used for the search.
Review the event’s matching rule and request context. A successful homepage visit from your own connection does not explain why the visitor’s request was blocked. The failed request is the example you need to understand.
Record the rule identifier, action, relevant condition, and affected path. If the visitor is sharing an IP address or other private details, keep that evidence within the support conversation rather than posting it publicly.
Decide whether the rule is working as intended
A targeted review should describe the legitimate request that must pass and the unwanted pattern the rule must still cover. For example, a contact form and a sensitive account endpoint may require different conditions. The administrator should evaluate any exception’s scope and duration and retain a way to restore the original configuration.
A block can be intentional or an unwanted match. The goal is to establish which applies. A condition intended to stop a specific unwanted pattern may also match a legitimate form request if its scope is broader than expected.
Consider a rule aimed at one sensitive endpoint. If its condition accidentally includes the public contact page, narrowing it may preserve the original protection while allowing the intended workflow. This is an example of a focused rule review, not a recommendation to turn off the site’s firewall.
Cloudflare’s support guidance is to identify the blocking security feature or rule in Security Events, then assess its configuration. An IP allowance is not a universal correction for validation failures. Use a supported change for the feature involved and review any exception’s scope and duration with its administrator.
Verify the visitor’s workflow after a focused change
Keep a copy of the original rule configuration, make the agreed adjustment, and retest the affected request. If it was a form submission, use harmless test data and check that the expected confirmation appears. Opening the form alone does not verify the submission path.
Review the new security event for the test where available. This connects the observed result to the intended rule behavior. It also helps distinguish a genuine repair from a request that happened to take a different path.
Try an unrelated public page to check normal access, but keep attention on the blocked workflow. For an access policy change, the administrator should also confirm that requests the policy was intended to reject remain covered.
If no matching event can be found, recheck the Ray ID, time range, time zone, and correct Cloudflare account. Keep the original screenshot for support. Changing unrelated settings while the failed request remains unidentified makes the investigation harder.
A short record of the false match and the final rule adjustment is helpful for future reviews. It explains why the exception or condition exists and prevents a later cleanup from recreating the same visitor problem.
Reference: Cloudflare error 1020 documentation.
Document the rule decision and test result
If the failure occurred during a form submission, opening the form is only the first check. Use harmless data to verify the submission and expected confirmation, then compare the new event with the intended rule behavior. Record the reason for the adjustment so a later cleanup does not recreate the same false match.