For the last few months, there has been a noticeable uptick in public conversations across webmaster forums, hosting communities, and security channels about aggressive bot traffic originating from China and Singapore. I can confirm this firsthand. What began for me in early October as a vague sense that something was off quickly turned into one of the most frustrating infrastructure problems I have dealt with in years.
On a typical day, my sites receive roughly a thousand real human visits. Almost overnight, that number was being inflated by hundreds of thousands of requests per day. At peak, traffic was effectively 500 times normal volume. These were not casual crawlers or polite scrapers. They were hammering thousands of URLs per hour, many of which did not exist, driving 404s, chewing through PHP workers, saturating database connections, and quietly increasing CDN costs along the way.
This was not training bots. If it were scraping for AI training, the entire site could have been copied in minutes. The behavior was closer to a resource-exhaustion attack, but lacked a clear motive or a single identifiable signature. Worse, I was far from alone. Across Reddit, Slack groups, and WordPress communities, countless site owners reported nearly identical patterns, often pointing to the same geographic sources.
What follows is how I ultimately stopped it without blocking entire countries outright, and why Cloudflare’s challenge-based controls proved the only reliable solution.
Why This Traffic Was So Hard to Stop
One of the most frustrating aspects of this attack pattern was its adaptability. Blocking individual IP addresses was pointless. Every time a block list was applied, new IPs appeared immediately. Rate limiting helped briefly, but the bots distributed requests more widely. User agent filtering was ineffective because the requests mimicked legitimate browsers well enough to slip through.
At one point, the volume was so intense that I was forced to remove wildcard redirects and temporarily disable on-site search. The bots were generating thousands of search requests per hour and probing URLs that did not exist. Even though the requests were invalid, WordPress still had to work to reject them, and that work adds up quickly under sustained load.
This is where many people misdiagnose the problem. The server is not slow. The application is not unoptimized. The infrastructure is being abused at a scale it was never designed to absorb continuously.
Why CDN Asset Caching Alone Is Not Enough
Like many publishers, I was already using Bunny as a traditional CDN, primarily for static assets. In that configuration, Bunny accelerates delivery but still allows most requests to reach the origin server. When the attack targets dynamic URLs, search endpoints, or nonexistent paths, caching provides little protection.
The turning point came when I realized I needed a CDN that acts as a true front-end firewall, not just a performance layer. I spent hours trying to configure Bunny on this with no success. I’m sure folks with more NGINX and infrastructure experience could have figured it out, but it was over my head. And if you’re an infrastructure expert, there are some great resources out there tracking the exact IPs that should be blocked.
FlyWP, where I’m managing WordPress on Linode, offers a deep Cloudflare integration that places Cloudflare directly in front of the site, allowing firewall rules, bot mitigation, and challenges to execute before traffic ever touches PHP or MySQL. That distinction matters. It is the difference between absorbing an attack and preventing it.
Identifying the Geographic Pattern
Once Cloudflare was fully integrated, the visibility alone was eye-opening. The majority of abusive traffic clustered tightly around two countries: China and Singapore. This does not mean all traffic from these regions is malicious. I have legitimate readers and partners worldwide. But the abuse pattern was unmistakable, sustained, and wildly disproportionate to real user behavior.
With this clarity, the goal became obvious. I needed a way to slow down or stop automated traffic from these regions without permanently blocking real people.
Why Interactive Challenges Worked When Blocks Failed
Cloudflare offers several mitigation options, but outright blocking is a blunt instrument. I never wanted to deny access entirely based on geography. Instead, I used an interactive challenge.
An interactive challenge forces the visitor to complete a browser-based verification before continuing. Real users pass through almost instantly. Automated systems fail, stall, or abandon the request entirely. Most importantly, this happens at Cloudflare’s edge, not on your server.
This single step changed everything. After initiating the challenge last night, I’ve seen a consistent drop off. The number of requests is startling in 24 hours, though!
Within minutes of enabling the rule, server load normalized. Database connections stabilized. CDN costs stopped climbing. The bots did not adapt.
How to Configure the Cloudflare Rule
The rule itself is surprisingly simple. Inside Cloudflare’s Security > Security Rules, create a new rule with the following logic.
The condition checks whether the visitor’s country is China or Singapore. The action applies an interactive challenge. Place the rule at the top of your firewall list so it executes before any broader rules.
Behind the scenes, Cloudflare translates this into a condition similar to checking whether the source country code is CN or SG. You do not need to write raw expressions unless you want to. The interface handles it cleanly.
The critical detail is choosing an interactive or managed challenge rather than a block. Challenges preserve access while eliminating automation.
Why This Finally Solved the Problem
Once Cloudflare was acting as a true gatekeeper, the attack lost its leverage. The bots were no longer able to generate unlimited requests at negligible cost. Every request required computation and browser capabilities that they did not have.
Equally important, this solution scaled. IP rotation stopped mattering. Request patterns stopped mattering. Even if the traffic shifted slightly in geography, Cloudflare’s analytics made it trivial to adapt the rule.
Most importantly, legitimate visitors were unaffected. Real users passed through seamlessly, often without even realizing a challenge had occurred.
A Broader Warning for Publishers
What worries me most is how many independent publishers and small businesses are being forced into infrastructure decisions they never anticipated. This kind of traffic can quietly bankrupt a site through hosting overages and CDN costs without ever fully taking it offline.
This is not about SEO, indexing, or AI training. It is about automated systems exploiting the openness of the web at scale. If you are experiencing sudden traffic spikes that do not convert, do not engage, and do not make sense, trust your instincts. Look at geographic distribution. Look at request paths. Look at cost anomalies.
You are probably not alone.
Final Thoughts
I never wanted to block countries, and I still have not. What I blocked was automation masquerading as legitimate traffic. Cloudflare’s challenge-based approach allowed me to preserve openness while defending infrastructure, and it was the first solution that actually held under sustained pressure.
If you are seeing massive unexplained traffic from China or Singapore, and nothing else has worked, this approach is worth serious consideration. It ended months of frustration for me in a single afternoon, and it restored control over resources that had been spiraling out of reach.
©2025 DK New Media, LLC, All rights reserved | DisclosureOriginally Published on Martech Zone: How I Finally Blocked China and Singapore Bot Traffic Using Cloudflare