Cloudflare Error 1015 — "You Are Being Rate Limited" Explained and Fixed

If a site has just handed you an orange-and-white Cloudflare page reading "Error 1015 — You are being rate limited", here is the single most useful fact: you have not been banned. You have been throttled.

Somebody who runs that website wrote a rule — something along the lines of "no more than 50 requests per minute from one IP address to /login" — and your traffic crossed it. Cloudflare enforces that rule at its edge, before the request ever reaches the site's own servers.

That distinction decides your fix. A throttle expires. A block does not. Most people who land on this page need to do nothing except stop pressing refresh.

What Error 1015 actually means

Error 1015 means the site owner configured a Cloudflare rate limiting rule, and requests from your IP address exceeded that rule's threshold inside its counting window. It is a temporary mitigation applied at Cloudflare's edge. It is not a ban, not a bot verdict, and not something Cloudflare decided about you on its own.

Every Cloudflare rate limiting rule has four parts, and knowing them tells you what you are up against:

• A matcher — which requests get counted. Often a specific path like /api/ or /login, sometimes the whole site, sometimes only POST requests.
• A characteristic — what the counter is keyed to. The default is the client IP address. More sophisticated setups key on an API token, a session cookie, or a JA4 fingerprint.
• A threshold and period — for example 100 requests per 60 seconds.
• An action and a timeout — block, managed challenge, or log, held for a duration the operator picks.

That last item is why nobody can tell you how long a 1015 lasts. Ten seconds and one hour are both ordinary configurations, and the number lives in a dashboard you cannot see.

One more detail worth internalising: on many rule configurations, requests that arrive while you are blocked still count. Hammering refresh is the most reliable way to keep yourself locked out.

Error 1015 vs 1020 vs 1006, 1007 and 1008

These codes get used interchangeably in forum answers and they should not be. Each one names a different Cloudflare mechanism with a different owner, a different lifespan and a different fix. Reading the number off the page correctly saves you from applying a fix designed for an entirely different problem.

The practical shorthand: 1015 is about how fast you went. 1020 is about who or what you appear to be. If waiting solves your problem, it was 1015. If waiting changes nothing, you almost certainly misread the code.

Fixes if you are an ordinary visitor

You are the most common case, and your fix list is short. In most situations the page comes back on its own within a minute or two, so the first two steps below resolve the overwhelming majority of consumer 1015 reports without changing a single setting.

1. Stop refreshing. This is genuinely the number one fix. Every retry can extend the block. Close the tab, wait, come back.
2. Wait sixty seconds, then try once. If that fails, wait five minutes and try once more. If it is still failing after fifteen minutes, the rule has a long timeout or you are still generating traffic you are not aware of.
3. Check who else is on your connection. Office and campus networks put everyone behind one public address. A colleague running a scraper, a monitoring dashboard polling every second, or a phone syncing aggressively will burn the shared budget. Test the same page on mobile data with Wi-Fi off — if it loads instantly, your network is the problem, not you.
4. Disable prefetching and aggressive extensions. Some privacy tools, download managers, and "link preview" extensions fetch every URL on a page in the background. From Cloudflare's side that is fifty requests you did not knowingly make.
5. Turn a consumer VPN off rather than switching servers. VPN exits are shared by very large numbers of people, so you often just swap into someone else's active rate limit. This is the same dynamic behind YouTube's "sign in to confirm you're not a bot" prompt.
6. Restart your router. On most consumer ISPs this requests a new address, which resets your counter. It also does nothing if the source of the traffic is a device still sitting on your LAN.

Fixes if you are a developer, scraper or API client

If your code caused the 1015, the goal is not to evade the rule — it is to stop tripping it, because a client that respects limits keeps working indefinitely while one that fights them escalates from a throttle into a firewall block. These changes are ordered by how much they actually help.

Respect Retry-After if it is present. Cloudflare's rate limiting can return a Retry-After header telling you exactly how many seconds to hold. Reading it and sleeping is the single highest-value line of code you can add. The mechanics of parsing it are covered in detail in the HTTP 429 guide.

Cut concurrency before you cut speed. Ten parallel workers each waiting one second between requests is ten requests per second, not one. Rate limits count arrivals at the edge, and they do not care how many threads produced them. Drop the worker pool first.

Add real delays with jitter. Perfectly regular timing is itself a bot signal. A random gap in a sensible range costs you very little and looks far less mechanical than a metronome.

Cache, and use conditional requests. Store what you already fetched. Send If-None-Match with the ETag you were given; a 304 Not Modified is cheap for both sides and on many configurations counts far less against you than a full fetch.

Carry a session. Use one requests.Session or equivalent, keep cookies, reuse the TCP connection. A client that accepts and returns cookies looks like a browser; one that discards them on every request looks like exactly what it is.

Back off exponentially when you do get limited. Retrying immediately at the same rate is how a ten-second timeout becomes an hour.

Why rotating your IP on every request is usually the wrong move

This is the most common bad advice on this topic, so it is worth being direct: swapping to a fresh IP for every single request generally makes you easier to detect, not harder.

The reasoning is straightforward. Rate limits are one layer. Behavioural and reputational scoring is another. A brand-new address with no history, sending exactly one request, carrying no cookies, then never appearing again — repeated thousands of times — is a pattern that no human browsing session produces. You have optimised away the per-IP counter and handed the WAF a much stronger signal instead.

What works better in practice is a stable address per session: one identity, holding cookies, moving at a plausible pace, for the duration of a task. Rotate between tasks, not between requests. That trade-off is the whole subject of dedicated vs rotating proxies.

When this becomes an infrastructure problem

Everything above is a client-side fix. There is a point past which client-side fixes stop mattering: when you have already reduced concurrency, added delays, cached aggressively, and you are still limited — because the site's threshold per IP is simply lower than the volume one address is allowed to produce. At that point the address itself is the constraint.

It is also worth naming the honest case where the address is not the constraint: if you are being limited because a site genuinely does not want the volume you are asking for, more IPs is not an engineering solution, it is a decision to ignore them. Whether that is appropriate depends on what you are collecting and why, and that judgement belongs to you rather than to a tool.

Where the address genuinely is the bottleneck, the type of address matters, because reputation scoring is applied before per-rule counting:

That last row is the reason mobile proxies exist as a product category at all, and it is explained in full in what is a mobile proxy.

Two caveats, stated plainly, because this is where proxy marketing routinely overclaims:

A mobile IP does not make you undetectable. It changes one input into a scoring system with many inputs. Request rate, session continuity, header consistency and TLS fingerprint all still count. A mobile address behaving obviously robotically will still collect a 1015 — and then a 1020.

A shared mobile pool reintroduces the problem you were trying to solve. If your mobile address rotates through a pool other customers also use, you inherit their rate limit counters, exactly as you would on a shared residential pool. A dedicated address used by one tenant is what removes that variable. QuantumProxy sells that specific shape — one real device, one tenant, sticky IP, rotation when you ask for it — but the point stands regardless of vendor.

A ten-second diagnostic

Before changing anything, run this. It separates "my network is rate limited" from "my code is rate limited" faster than any amount of log reading.

Load the same URL on your phone with Wi-Fi turned off.

If it loads, your original network's address is the one carrying the limit, and you should look at what else is sharing that connection. If it still fails on a completely separate address, then the limit is following something other than your IP — an API token, a session cookie, or an account — and no amount of network switching will help.

And if the page you get on the second attempt says 1020 rather than 1015, you have a different problem entirely, and the Error 1020 guide is the one you want.

Frequently asked questions

How long does Cloudflare Error 1015 last?

It lasts exactly as long as the site owner configured. Cloudflare rate limiting rules let the operator set a mitigation timeout, and in practice these range from about ten seconds to an hour. There is no universal number, and no way to look it up from the outside — which is why waiting a minute and retrying once is the correct first move.

Is Error 1015 a ban?

No. It is a throttle that expires on its own. A ban shows up as Error 1006, 1007 or 1008, and those do not clear with time. If your error code is 1020 you have hit a firewall rule instead, which also does not expire on its own.

Why do I get 1015 when I barely used the site?

Because the limit is usually counted per IP address, not per person. On office Wi-Fi, a university network, a shared VPN exit or carrier-grade NAT, dozens or thousands of people leave from the same address. One colleague running a script can consume the budget for everyone behind it.

Will a VPN fix Error 1015?

Sometimes for a moment, then usually not. A VPN gives you a fresh address, so the counter resets — but commercial VPN exits are shared by very large numbers of users, so you often land straight back into somebody else's rate limit. Turning the VPN off is more likely to help than switching servers.

Does rotating my proxy IP on every request avoid 1015?

It avoids the per-IP counter and creates a different problem. A stream of single-request addresses with no cookies and no session history is a recognisable automation pattern, and sites that care will respond with a firewall rule rather than a rate limit. Slower, sessioned requests from a stable address survive longer in most cases.

Can I contact the site to get unblocked?

You can, and it is worth doing for a business-critical API. Cloudflare's 1015 page shows a Ray ID at the bottom — include it, along with the approximate time and what you were doing. The site owner can look that Ray ID up and see exactly which rule you matched.