Key Points: Why You’re Seeing “Fake Traffic” From China and Singapore
If Google Analytics shows a sudden surge of users from Singapore or China, it often doesn’t mean real people in those countries are attacking your site. In many cases, you’re seeing a mix of automation, crawler routing, and analytics miscounting.
To the point: what’s actually happening
-
Some traffic is real bot automation. Headless Chromium scrapers may impersonate future browser versions like Chrome 142 to 145 and hammer the same files repeatedly.
-
Singapore is often a Cloudflare edge location, not the true origin. Cloudflare may show the POP that handled the request, like Singapore, Tokyo, or Hong Kong, even when the traffic belongs to major platforms or crawlers.
-
Google Analytics counts JavaScript capable bots as users. If something executes JavaScript and fires a pageview, GA can count it as an active user even when no human ever visited.
With that in mind, here’s how this usually starts.
Most “fake traffic” stories start the same way: you open Google Analytics and see a wall of active users from Singapore, China, or India. Your server feels heavier. Your conversion rate doesn’t budge. Then you notice the user agents look… weird. Chrome 142? Edge 144? Versions that feel like they’re from the future.
It’s easy to jump to the obvious conclusion: someone in Singapore or China is flooding my site with bots.
That conclusion feels right because it matches what the dashboard shows. The problem is that dashboards can be misleading—especially when Cloudflare is in the middle and when the “bots” are smart enough to run JavaScript.
What looks like one problem is usually three separate things stacked on top of each other.
Why This “Fake Traffic” Panic Keeps Happening
When webmasters first notice it, the symptoms are usually a combination of:
- Sudden traffic spikes from Singapore, China, or India
- Google Analytics showing hundreds or thousands of “active users”
- Browser user agents claiming to be Chrome 14x, Edge 14x, or other “future” versions
- More server load, but no matching engagement, leads, or purchases
That combo pushes you toward a simple explanation: foreign bot attack.
But the truth is messier. And once you see what’s actually happening, the fix changes completely.
The Problem Most Webmasters See
A dashboard problem disguised as a security problem
A lot of site owners diagnose traffic the same way they diagnose marketing performance: by looking at Google Analytics first.
That’s understandable. GA is where the numbers are. It’s where the graphs are. It’s where “active users” looks like a live heartbeat monitor for your business.
But security problems don’t behave like marketing problems.
Security problems show up in logs, patterns, headers, request frequency, and IP ownership. Marketing problems show up in sessions, engagement time, and funnel drop-offs.
When you try to debug bot traffic with a marketing tool, you get half-truths—and the half you don’t see is the part that matters.
What We Actually Found
After digging into request logs and testing Cloudflare rules in real time, a clear pattern emerged: three different sources of “weird traffic” were being lumped together and blamed on geography.
The real issue: multiple traffic types wearing the same mask
Here’s what was actually happening:
- There was real automation (headless Chromium scrapers), and it was worth stopping.
- The “Singapore/China origin” was often not the origin at all—it was a routing artifact.
- Google Analytics was counting JavaScript-capable bots as real users, which inflated the panic.
Once those were separated, the situation stopped looking mysterious and started looking predictable.
Fake Browsers Are Real, But They Aren’t Human Traffic
Yes—some of the traffic is fake in the way people mean it: it’s not human, it’s automated, and it’s pretending to be a normal browser.
The giveaway: “future” browser versions
The biggest red flag was the user agent string. When you see things like:
- Chrome/142
- Chrome/143
- Chrome/144
- Chrome/145
…and you’re seeing them across huge volumes, that’s not early adoption. That’s automation trying to blend in while staying ahead of basic bot filters.
Other strong indicators that it’s headless scraping
In isolation, a single signal can be misleading. Together, these signs are hard to ignore:
- Thousands of IPs rotating rapidly
- Identical request sequences repeating across different countries
- The same endpoint being hit over and over with unnatural consistency
- Odd “must-fetch” behavior around specific assets
And one asset showed up more than anything else:
Why /site.webmanifest Became the Smoking Gun
If you’ve never looked closely at it, /site.webmanifest is typically just a small file used for Progressive Web App metadata. Real browsers don’t obsess over it.
What real browsers normally do
A normal browser tends to:
- Request it once (or not at all)
- Cache it
- Move on
- Not break if it errors
In real-world browsing, plenty of users never request it, and many sites wouldn’t notice if it disappeared for a day.
What headless frameworks often do instead
A lot of headless Chromium automation behaves like it’s checking boxes:
- “Load page”
- “Fetch manifest”
- “Fetch icons”
- “Validate assets”
So instead of a casual request, it treats the manifest as mandatory and repeats it aggressively, sometimes as part of a scripted loop.
The simple test that proved it
When /site.webmanifest was blocked, the “fake Chrome” traffic collapsed immediately.
That didn’t just reduce the spike—it separated the noise from the signal. The automation traffic wasn’t mysterious anymore. It was measurable, repeatable, and stoppable.
Singapore and China Were a Red Herring
Here’s where most people get led off a cliff.
After blocking the scraper behavior, the site still showed “surges” from Singapore—sometimes China, sometimes India. So it looked like the block didn’t work.
But it did work. The remaining traffic wasn’t the same thing.
The key insight: Cloudflare shows the edge location, not the true corporate origin
When Cloudflare is in front of your site, requests often come through a Cloudflare POP (point of presence). Those POPs can be in places like:
- Singapore
- Tokyo
- Hong Kong
So what you’re seeing in many dashboards and reports isn’t “where the user lives.” It’s “which Cloudflare facility handled the request.”
That matters because major companies route their crawler infrastructure through strategic global hubs.
What the IP ownership check revealed
When the IPs were checked for ownership (ASN / range data), the “Singapore traffic” turned out to be things like:
- Meta (Facebook) IPv6 ranges
- Applebot
- SEO crawlers
- Analytics collectors and verification traffic
None of these are residential humans sitting in Singapore clicking your homepage.
And most of them aren’t attackers.
They’re just automated systems doing what automated systems do—moving fast, requesting assets oddly, and showing up in places you don’t expect.
Google Analytics Is Not a Bot Detector
This is the part that causes the most damage, because it leads people to block the wrong countries, break their marketing pipeline, and then wonder why things got worse.
What GA actually counts
Google Analytics counts activity when JavaScript executes and events fire.
So if a visitor (human or not):
- Loads the page
- Executes JS
- Fires a pageview
- Accepts cookies (or simulates them)
…GA will happily count them as a user.
Why that matters now more than ever
Modern bots can execute JavaScript.
That means things like:
- Facebook link preview bots
- SEO crawlers
- Validation tools
- Headless testing frameworks
…can show up in GA as: “Active users from Singapore”
Even when no human ever saw your page.
Why logs and GA don’t match—and why the logs win
GA is a measurement layer. Your server logs are a reality layer.
If GA says you had 1,200 active users from Singapore, but your logs show patterns like:
- repeated manifest hits
- systematic asset loops
- known crawler ownership ranges
Then GA is telling you “JavaScript ran,” not “people visited.”
When the two disagree, trust the logs.
Why Geo-Blocking Makes Everything Worse
Geo-blocking feels satisfying because it gives you a clean before-and-after chart. You block Singapore and the “Singapore spike” drops.
Then a day later it’s Tokyo. Then Hong Kong. Then somewhere else.
Because you didn’t stop the cause—you just forced the traffic to take a different path.
What geo-blocking breaks in the real world
When you block entire countries or regions, you can accidentally break:
- Social previews (link unfurling on Facebook, iMessage, Slack, etc.)
- Search indexing and discovery
- Legitimate third-party verification systems
- Real travelers or international customers (if relevant to your market)
Even if you don’t care about international users, blocking entire regions is still a blunt tool. It creates false confidence and encourages you to ignore the real behavioral signatures.
The uncomfortable truth
If the traffic is routed, “country” was never the root cause.
So blocking geography is like treating a fever by smashing the thermometer.
The Correct Fix
The fix is not “block Singapore.” The fix is “stop automation behavior, then correctly classify crawler traffic, then clean up analytics.”
Step 1: Stop real automation with behavioral rules
Don’t block based on where traffic appears to come from.
Block based on what it does.
Behavior you can reliably act on includes:
- abnormal repeat requests for specific assets (
/site.webmanifestis a common one) - repeated identical request patterns
- suspicious user agent combinations
- lack of normal browser navigation behavior
If you stop the repetitive automation loops, your server load drops and the fake “future Chrome” noise tends to vanish fast.
Step 2: Accept that crawler traffic exists (and it’s not all hostile)
Not all “fake-looking” traffic is malicious. Some of it is simply:
- social preview generation
- search indexing
- performance and availability checks
- analytics validation
Treating all crawlers as attackers leads to self-inflicted damage.
Step 3: Fix analytics instead of trying to force Cloudflare to behave like GA
GA is not built to be your security monitoring system.
If you want GA numbers to reflect humans more accurately, you need to filter out known crawler and automation signals inside GA (and ideally cross-check with server-side analytics or log-based measurement).
If you don’t, GA will keep “lying” in the same way: counting JS execution as human presence.
Cloudflare Rule Examples That Work
These rules aren’t magic, but they’re effective because they aim at behavior and known indicators instead of geography-first assumptions.
Skip rule: let verified bots through
Example Rule 1 = Skip: cf.client.bot
This prevents you from wasting time fighting verified crawlers and keeps your controls focused on the unknowns.
Block the manifest endpoint for non-verified bots
Example Rule 2 = Block: http.request.uri.path contains "/site.webmanifest" and not cf.client.bot
This is the fastest “pressure test” rule: if your spikes collapse, you just proved the traffic was automation-heavy.
Block suspicious “future Chrome” manifest requests
Example Rule 3 = Block: http.request.uri.path eq "/site.webmanifest" and http.user_agent contains "Chrome/142.0.0.0" and not cf.client.bot
Example Rule 4 = Block: http.request.uri.path eq "/site.webmanifest" and http.user_agent contains "Chrome/143.0.0.0" and not cf.client.bot
These are narrow, targeted cuts. They don’t punish real browsers broadly—they just shut down obvious impersonation patterns tied to the problem endpoint.
Add friction for non-US traffic (carefully)
Example Rule 5 = JS Challenge: (ip.src.country ne "US" and not cf.client.bot)
This can be useful as a temporary control, especially if your audience is almost entirely US-based. But it’s still geography-based, so it should be treated as a tuning knob—not your main strategy.
If you rely on this alone, you’ll end up chasing POP locations forever.
The Core Lesson for Webmasters
If you diagnose traffic by country and Google Analytics alone, you will almost always block the wrong thing.
To understand what’s actually happening, you need to look at:
- Server logs (request frequency, paths, headers, patterns)
- IP ownership (ASN and known ranges)
- Request behavior (what’s being requested, how often, and in what sequence)
What looks like “fake traffic from Singapore” is often just:
- Cloudflare routing artifacts
- corporate crawlers and preview bots
- JavaScript-capable automation being counted as “users”
Final Takeaway
Fake Chrome traffic absolutely exists—and it often pretends to be future browser versions because it’s trying to slip past lazy filters.
But “Singapore” and “China” are usually not the attacker’s living room. They’re just part of how global routing and CDN infrastructure works.
If you want clean results:
- stop automation with behavior-based rules
- don’t punish entire countries because a POP showed up in a report
- treat GA as a marketing measurement tool, not a bot detection system
Once you separate automation from routing artifacts and analytics miscounting, the whole situation stops being spooky—and starts being manageable.
