Business

The Truth About “Fake Traffic” From China and Singapore

By Caleb Price Updated Jan 19, 2026 Category Business Read 12 min

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.webmanifest is 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.