Cloudflare Error 1020 / 1015: Access Denied & Rate Limited

What this error means & how to recognize it

• A Cloudflare-branded error page appears instead of the requested website or resource.
• The page explicitly shows Error 1020: Access denied or Error 1015: You are being rate limited.
• The response commonly includes a Cloudflare Ray ID, approximate time and affected hostname.
• Error 1020 may affect a specific IP address, path, request pattern or security-rule condition while other visitors continue to connect.
• Error 1015 may clear after request activity falls, recur during bursts or affect users sharing one public IP through NAT, a proxy or a corporate gateway.
• The request may have been stopped at Cloudflare’s edge before the origin application handled it. Compare the error with origin logs rather than assuming every similar failure has the same cause.

Root causes, ordered by likelihood

Most likely causes

1. A Cloudflare firewall, WAF or security rule matched the request (1020). The rule may evaluate the source IP, country, URI path, HTTP method, headers, user agent or another request attribute.
2. A configured rate-limit threshold was exceeded (1015). Repeated page loads, API polling, crawlers, parallel downloads, login attempts or many users behind one shared address can trigger the policy.
3. A security policy is broader than intended. A rule designed for an administrative path or abusive traffic may also match a legitimate visitor, monitoring service, office network or API client.
4. A shared or unusual source-IP pattern caused a match. VPNs, proxies, carrier NAT and corporate gateways can make unrelated users appear to come from one address.
5. A recent Cloudflare configuration change introduced the block. This is especially plausible when the error began immediately after a firewall, WAF, bot or rate-limit change.

These errors are not, by themselves, evidence that the origin server is down. A blocked request may never reach the origin, while a separate origin problem can produce a different response.

How to fix it

If you are a visitor

1. Record the complete error page. Note whether it says 1020 or 1015, the Ray ID, timestamp, time zone, hostname and URL or action that failed. Do not share passwords, tokens or other sensitive request data.
2. Stop rapid retries. If the error is 1015, wait before trying again. Repeated refreshes, parallel tabs and automated retries can prolong or repeatedly trigger the rate limit.
3. Pause avoidable request sources. Stop download managers, aggressive browser extensions, scripts, API polling, crawlers or other tools repeatedly requesting the same site. If appropriate, try one normal browser request without a VPN or proxy, but do not bypass an access control you are not authorized to bypass.
4. Check whether the problem is narrow or site-wide. A single path, account action or network may be blocked while other pages work. A successful request from another network does not prove that the site is healthy for everyone.
5. Contact the website operator. Provide the error number, Ray ID, timestamp, affected URL, a description of what you were doing and your public IP address only if the operator requests it and sharing it is appropriate.

If you manage the Cloudflare zone

1. Confirm the response layer. Check the Cloudflare branding, error number, Ray ID and timestamp. Compare the event with origin access logs; if there is no corresponding origin request, the block likely occurred at Cloudflare’s edge.
2. For Error 1020, inspect security events and matching rules. Use the Ray ID, time, source IP and request path to identify the firewall rule, WAF or custom rule, access policy or other control that denied the request. Review the rule expression instead of disabling all security controls.
3. For Error 1015, inspect rate-limit analytics and configuration. Identify the matching hostname, path, method, client identity and threshold. Check whether many legitimate users share an address through NAT, a proxy or a corporate gateway.
4. Compare blocked and allowed requests. Check the path, query string, method, headers, source network and request frequency. This helps distinguish a false positive from genuinely excessive or hostile traffic.
5. Make the smallest authorized change. Narrow the rule expression, correct an unintended condition, create a narrowly scoped exception or adjust the rate-limit policy for the affected endpoint. Preserve stronger controls on authentication and administrative paths unless the responsible security owner approves otherwise.
6. Test safely and monitor. Use an authorized test request representing the affected traffic. Confirm that legitimate access works while the intended protection still triggers for traffic it was designed to control. Review Cloudflare events and origin logs after the change.
7. Escalate with evidence if the match is unclear. Keep the Ray ID, timestamp and time zone, rule identifier or policy name, hostname, path, source-network context and relevant event details. Avoid repeatedly changing rules without recording each result.

Prevention & how to verify the fix

• Keep firewall and WAF expressions as narrow as practical, especially for public pages, APIs and shared networks.
• Scope rate limits using the appropriate combination of path, method, client identity and traffic pattern instead of relying on a broad global threshold.
• Account for NAT, VPN, proxy and corporate egress addresses as shared identities when assessing legitimate traffic.
• Review security events after deploying or changing rules, including traffic from normal users, monitoring systems and API clients.
• Give support teams a standard process for collecting the Ray ID, timestamp, hostname and affected path instead of repeatedly retrying.
• Document the difference between Cloudflare-edge blocks and origin errors so responders inspect the correct logs first.
• Record narrowly approved exceptions and review them periodically; avoid permanent broad allowlists that weaken protection.