What triggers Cloudflare 1015
Site owners configure rate-limiting rules in their Cloudflare dashboard — "if a single IP makes more than N requests in M seconds against path X, block for T minutes." When your scraper crosses that threshold, Cloudflare's edge serves the 1015 page instead of forwarding the request. Common rule shapes are 10 requests per 10 seconds for login endpoints, 100 per minute for catalog pages, or stricter limits on search and pricing endpoints. The ray ID in the error page is unique to your blocked request — you can give it to the site owner if you have a legitimate need, but for unaffiliated scraping that's not an option.
How to recover from a 1015
The block is per-IP and time-bound. Switching to a different IP via proxy rotation clears it immediately. The right pattern is to detect the 1015 marker in the response body, mark the current IP as cooling-off for the block duration (often visible in the error message), and route subsequent requests through a different IP. If you don't rotate proxies, your only option is to wait — the block typically clears in 5–60 minutes depending on the rule. Continuing to retry from the same IP during the cooldown extends the block on many configurations.
How to avoid 1015 in the first place
Lower your per-IP request rate. The defaults that trigger 1015 are usually around 100+ requests per minute per IP — staying well below that across each IP in your pool keeps you clear. Spread load across a larger proxy pool so each IP individually looks like normal traffic. Add jitter between requests so you don't show up as the perfectly-spaced pattern that rate-limiting rules pattern-match against. And cache: if you've already pulled a page recently, don't fetch it again. Most 1015 incidents come from scrapers that over-allocated concurrency to a single proxy without measuring.