Cloudflare + Google Analytics: Tracking Down Suspicious International Traffic

DNX | 2 hours ago

Recently I noticed something odd in Google Analytics.

The website serves primarily United States and Canadian users, yet Google Analytics Realtime and Demographic reports consistently showed active visitors from countries such as Bangladesh, Vietnam, Venezuela, China, France, and others.

At first glance, it looked like ghost traffic. The origin server wasn't showing any obvious spikes, CPU usage remained low, and Cloudflare was sitting in front of the site.

This post documents the investigation and what I learned.

Initial Symptoms

Google Analytics showed:

Unexpected countries

Many "Direct" visitors

Traffic appearing throughout the day

My first questions were:

Is Google Analytics wrong?

Is this ghost traffic?

Are bots actually reaching my server?

Is Cloudflare already stopping them?

Step 1 — Check Cloudflare Traffic by Country

The first place to look is Cloudflare Analytics.

Go to:

Cloudflare Dashboard
→ Analytics & Logs
→ Traffic

Under Top Traffic Countries/Regions, you'll see requests by country.

Example:

United States
Bangladesh
Vietnam
China
France
...

This immediately answered one question:

The traffic was real.

Cloudflare itself was seeing requests from those countries.

Step 2 — Are They Reaching the Origin?

Seeing traffic in Cloudflare doesn't necessarily mean it reaches your server.

Cloudflare may:

serve cached pages

block requests

challenge visitors

forward requests to the origin

To determine which is happening, compare:

Apache/Nginx logs

Cloudflare Analytics

Origin CPU/load

In my case:

Origin load stayed low.

Most pages were cached.

That suggested Cloudflare was serving much of the traffic from its edge.

Step 3 — Review Existing WAF Rules

I already had a WAF rule protecting expensive dynamic pages such as:

/swimmer
/rankings
/meet-results
...

Those paths required a Managed Challenge.

However, everything else remained accessible:

/
favicon.ico
images
css
javascript
robots.txt
...

Bots could still:

visit the homepage

load cached assets

execute Google Analytics

without ever touching expensive backend endpoints.

Step 4 — Inspect Security Events

This turned out to be the most valuable debugging step.

Go to:

Cloudflare Dashboard
→ Analytics & Logs
→ Security
→ Events

(Depending on your plan and the current UI, Security Events may appear under Analytics.)

Now filter by:

Country

WAF Rule

Action

Open individual events.

Useful information includes:

Country

IP

ASN

User Agent

URI

Rule matched

Action taken

For example, an event might show:

Country:
Bangladesh

URI:
/favicon.ico

Action:
Managed Challenge

ASN:
...

That immediately tells you:

which requests are occurring

whether your WAF rule matched

exactly which URLs are being requested

This view is incredibly useful when debugging WAF behavior.

Step 5 — Compare with Google Analytics

GA4 makes it easy to see where traffic originates.

Useful reports:

Reports
→ User
→ User attributes
→ Demographic details

Set the dimension to:

Country

For more flexibility, use:

Explore
→ Free Form

Dimensions:

Country

Metrics:

Active Users

Sessions

Views

Engagement Time

This quickly shows whether suspicious countries continue generating sessions.

Why the Server Wasn't Busy

One confusing part was:

Why wasn't the server under heavy load?

The answer was Cloudflare caching.

The sequence looked like this:

Bot
    │
    ▼
Cloudflare Edge
    │
    ├── Cached homepage
    ├── Cached JS
    ├── Cached CSS
    ├── Cached images
    │
    └── Dynamic pages
            │
            ▼
        Origin Server

Most requests never reached the origin.

Instead:

Cloudflare served cached content.

Google Analytics still executed in the visitor's browser.

GA therefore recorded sessions even though Apache saw relatively little activity.

Solution

Rather than protecting only selected dynamic pages, I added another WAF rule above the existing one.

The new rule applies a Managed Challenge to visitors outside the primary audience countries.

For example:

Host = example.com
AND Country NOT IN (US, CA)
AND NOT Verified Bot

Action:

Managed Challenge

The original WAF rules remain in place to protect sensitive endpoints.

This creates two layers:

International traffic is challenged immediately.

Dynamic pages continue to have their own protection.

Lessons Learned

Several assumptions turned out to be incorrect.

❌ Google Analytics showing foreign countries does not automatically mean ghost traffic.

❌ Low server load does not mean bots aren't visiting.

❌ Protecting only dynamic endpoints still allows bots to browse cached pages and execute analytics.

The most useful tools during this investigation were:

Cloudflare Traffic Analytics

Cloudflare Security Events

Google Analytics Demographic reports

Origin access logs

Together, they provide a complete picture of where traffic is coming from, how Cloudflare is handling it, and whether requests ever reach your server.

Final Thoughts

If your website primarily serves users from a small set of countries, don't assume suspicious international traffic is harmless just because your server isn't overloaded.

Cloudflare's cache can absorb a large volume of requests, masking the true scale of automated traffic. Reviewing Traffic Analytics, Security Events, and GA4 country reports together can quickly reveal whether your WAF rules are protecting only expensive endpoints—or whether bots are still freely accessing cached pages and inflating your analytics.

For me, the biggest takeaway wasn't just improving security. It was learning how to use Cloudflare's analytics and event logs to understand exactly who was visiting, what they were requesting, and how Cloudflare was handling each request. That visibility made it much easier to make informed decisions about tightening WAF rules without guessing.