If a visitor sees "Error 1015: You are being rate limited" on your site, don't reach for your server logs first — this one happens entirely inside Cloudflare's network, before the request ever reaches your origin. It's a different beast from the 520/521/525-family errors, which are about your server not answering Cloudflare's requests. A 1015 means Cloudflare itself decided the visitor was sending too many requests too fast and cut them off.
Symptom: What You'll See
The page is orange-and-white, branded as Cloudflare, and reads something like:
Error 1015 Ray ID: 8a2f1c9e0d3b4a12 • Your IP: 203.0.113.45
You are being rate limited
Sometimes it's a single visitor complaining. Sometimes it's every visitor from one office, one mobile carrier, or one country hitting a wall at once — which is usually the tell that it's a shared-IP problem, not an actual attack.
Cause: Why Cloudflare Is Blocking Your Own Traffic
Error 1015 fires when a request trips a rate-based rule somewhere in your Cloudflare zone. In practice it's almost always one of these:
- A Rate Limiting Rule you (or a previous admin) configured — under Security > WAF > Rate limiting rules — with a threshold that's tighter than real traffic patterns.
- Bot Fight Mode or Super Bot Fight Mode, which treats fast, repeated, script-like requests as bot behavior — this catches mobile apps, API integrations, WooCommerce polling, and monitoring tools more often than people expect.
- A managed WAF rule that includes rate-based detection for things like login endpoints or search forms.
- Shared IP / CGNAT traffic. If a rule is set per-IP and dozens of real users sit behind the same corporate NAT or mobile carrier IP, they collectively look like one very aggressive client.
- "I'm Under Attack Mode" left on longer than the actual attack, still issuing JS challenges and rate checks to normal visitors.
Note what it's not: your PHP-FPM limits, your cPanel CSF/LFD firewall, or Apache/Nginx limit_req settings. Those live on your origin server and would never produce a Cloudflare-branded error page. If you're chasing this in your server's error log, you're looking in the wrong place — it won't show up there at all.
Fix: Find the Rule, Then Loosen or Exempt It
Step one is always the same: find out which rule fired, rather than guessing.
- In the Cloudflare dashboard, go to Security > Events.
- Search by the Ray ID from the error page, or filter by the affected IP/time window.
- The event log names the exact rule — a specific Rate Limiting Rule, a WAF managed rule ID, or Bot Fight Mode — and the action taken (Block, Challenge, JS Challenge).
Once you know the culprit, pick the matching fix:
| Trigger | Fix |
|---|---|
| Custom Rate Limiting Rule too strict | Edit the rule: raise the request threshold, lengthen the counting period (e.g. 60 requests/60s instead of 20/10s), or narrow its match condition so it only targets the endpoint you actually meant to protect (like /wp-login.php, not the whole site). |
| Bot Fight Mode blocking real clients | Under Security > Bots, either turn it off, or add the offending path/User-Agent to a Custom Rule with a Skip action for "Bot Fight Mode" before it runs. |
| WAF managed rule with rate component | Security > WAF > Managed rules — find the specific rule ID from the event log and set it to Log or add an exception scoped to the path/IP that needs it. |
| Office/shared IP getting caught | Add a Custom Rule: match the known IP range, action Skip > "Rate Limiting Rules" and/or "Bot Fight Mode". Don't skip the whole WAF — just the rate check. |
| Left in "I'm Under Attack" too long | Switch Security Level back to Medium/Essentially Off once traffic is normal — this mode is meant to be temporary. |
If you manage the site through SkyServer and don't have Cloudflare access yourself (some customers point DNS through a reseller or agency's Cloudflare account), you'll need whoever owns that Cloudflare zone to make the change — we can't edit rate-limiting rules from the hosting side, since they live entirely in Cloudflare's control plane.
Prevention: Set Thresholds From Real Data, Not Guesses
Most 1015 incidents are self-inflicted from copying a "recommended" rate-limiting template without checking it against actual traffic. Before enabling or tightening any rate rule:
- Check Analytics & Logs > Traffic for your busiest legitimate endpoints (checkout, search, REST API, admin-ajax) and note their normal requests-per-minute from a single IP during peak hours.
- Set new rules to Log mode first, watch the Security Events tab for a day or two, then flip to Block once you're confident it's not catching real users.
- Scope rules narrowly — rate-limit
/wp-login.phpand/xmlrpc.phpaggressively (they should never see bursts from real visitors), but leave general page traffic and REST API endpoints with generous headroom. - If you run WooCommerce or any plugin that polls
admin-ajax.php(cart fragments, stock checks), give that endpoint a separate, looser rule — it's a common false-positive source. - Re-review rules after any major traffic change: a marketing campaign, a new mobile app release, or moving from a handful of office users to remote staff on shared VPN egress IPs.
Frequently Asked Questions
Is Error 1015 caused by my hosting server or PHP configuration?
No. It's generated entirely by Cloudflare's edge network before the request reaches your server. Server-side limits like PHP-FPM's pm.max_children or a cPanel CSF firewall rule can cause other errors (502, 503, connection refused), but never this specific Cloudflare-branded page.
How do I know exactly which rule blocked the visitor?
Go to Security > Events in the Cloudflare dashboard and search using the Ray ID printed on the error page, or filter by the visitor's IP and approximate timestamp. The log entry names the specific rule and action.
Will turning off Bot Fight Mode fix it right away?
If Bot Fight Mode is the confirmed trigger (check the Events log first), yes — disabling it or adding a Skip rule takes effect immediately, no propagation delay involved since it's a dashboard-only setting.
Can real customers get blocked by this even though they're not attacking anything?
Yes, and it's common. Anyone behind a shared IP — office NAT, mobile carrier CGNAT, a VPN, or a corporate proxy — can trip a per-IP threshold just by being one of many people using that IP at once. This is the most frequent false positive.
How long does a rate-limit block from Error 1015 last?
It depends entirely on how the rule is configured — the "mitigation timeout" on a custom Rate Limiting Rule can be anywhere from a few seconds to hours. Check the specific rule's settings rather than assuming a fixed duration; there's no universal Cloudflare-wide timer.
