I run a nonprofit educational website built with Django, Gunicorn, and Nginx behind Cloudflare. Starting around 1:00 AM on August 8, the server began experiencing repeating CPU spikes roughly once per minute. CPU usage rose from about 20% to 60–90%, while existing Gunicorn workers became busy and MariaDB reached approximately 300% CPU.
The load was caused almost entirely by requests to the homepage (`GET /`). The source address changed almost every request, with sampled IPv4 and IPv6 addresses spread across unrelated residential and mobile networks in many countries. The requests generally had no referrer and used Chrome-on-Windows user agents with rotating browser versions. Around 92,000 unique addresses accounted for approximately 112,000 requests, making ordinary per-address rate limiting ineffective. The synchronized, approximately 60-second waves also make normal human traffic unlikely.
The homepage was relatively expensive because it performed several database queries, including random selections. Adding a 60-second Django full-page cache immediately eliminated the CPU spikes. I also added a Cloudflare cache rule for `/`, and Cloudflare is now serving cache hits so the requests rarely reach the origin.
Spot checks found little useful abuse-reporting data. In one analysis covering the traffic from 1:00 AM onward, about 69,691 requests came from 60,967 unique addresses across more than 6,700 ASNs. The largest country groups included Brazil, the United States, Vietnam, Mexico, France, India, Bangladesh, Argentina, and Pakistan.
Has anyone encountered this combination of one-shot residential or mobile IPs, rotating Chrome user agents, and synchronized waves? Does it point more toward a residential proxy service, compromised routers or other devices, a botnet, or a distributed measurement system?
4 Answers
Abuse databases probably will not tell you much here. A globally distributed residential pool may have no common ownership, and many of the addresses may be clean or compromised without being reported. ASN and country counts are still useful for documenting the event, but they are unlikely to identify one operator by themselves.
This looks very consistent with a residential proxy network or a distributed botnet. Residential and mobile addresses have relatively clean reputations, and rotating through them makes IP-based blocking almost useless. The fact that each address makes only one or a few requests is also typical of proxy rotation or compromised-device traffic. The synchronized waves suggest centrally scheduled activity rather than ordinary browsing.
The caching fix is the most important result here. The requests were expensive because every hit reached Django and triggered database work, so caching the homepage at the application and edge layers removed the attacker’s leverage. Even if the traffic continues, Cloudflare can absorb most of it without repeatedly waking Gunicorn and MariaDB.
It may still be worth checking the cache configuration carefully. Make sure the rule applies to the exact homepage variants you serve and that query strings or cookies cannot force an origin fetch for every request.
We saw a similar incident at a university site: many residential addresses made only a handful of requests each, and there was no useful network range to block. Caching was already enabled, and identifying the traffic by a shared TLS or JA4 fingerprint worked better than IP filtering. I would compare the fingerprint, request headers, HTTP version, and connection behavior across the samples.
A fingerprint can be useful, but I would treat it as a signal rather than a permanent block rule. Modern proxy systems can vary TLS and browser characteristics, and an overly broad fingerprint rule could catch legitimate visitors.
Compromised home routers and other residential devices are another plausible source. A large infected population can produce globally distributed bursts, although the browser-like user agents could also be generated by the controller rather than by real browsers.