Overview

This case study covers how I set up free Cloudflare security rules to block traffic from specific countries, the gotchas I hit while testing (especially with VPNs), and how I verified everything was working properly.

The Problem

The site’s analytics were showing a high volume of traffic that looked spammy and low quality (likely bots). It wasn’t converting, wasn’t useful, and was making it harder to trust reporting.

    The client wanted to:
  • • Reduce irrelevant visits showing up in analytics
  • • Improve security posture with minimal disruption
  • • Stop suspicious requests before they hit the site
  • • Keep the solution easy to maintain over time

The Solution

I implemented Cloudflare (on the free plan) in front of the site and created security rules to block requests from specific countries. Cloudflare was the ideal fit here because it operates at the edge, meaning unwanted traffic can be blocked before it reaches the origin platform which was exactly what we needed in this scenario.

Implementation

1) Created and configured Cloudflare

  • ✓ Created a Cloudflare account and added the client’s domain
  • ✓ Updated DNS/nameservers in the registrar
  • ✓ Confirmed traffic was being proxied through Cloudflare

2) Created security rules to block targeted traffic

Rather than combining everything into one giant rule, I created separate rules per country. This keeps the setup easy to understand, simpler to maintain and quick to extend later if additional regions need blocking.

    Each rule followed this format:
  • • Field: Country
  • • Operator: equals
  • • Value: (target country)
  • • Action: Block

3) Verified rules were working

To confirm that blocking was working properly, I tested the setup in two reliable ways:

  • 1. Country blocking test (VPN): to simulate traffic from other regions
  • 2. IP blocking test: to prove the rules were firing instantly and consistently

Testing & Validation

Testing is key here, because “saving a rule” doesn’t always tell you whether it’s actually firing correctly in real-world traffic.

Cloudflare Security Rules panel

I used the Security Rules view to confirm:

  • ✓ The rules were active
  • ✓ The rules were ordered correctly
  • ✓ Each rule had the expected action (“Block”)

Cloudflare Events log

This was the most useful validation tool. It let me see blocked requests in real time, including what triggered them, and which activity was mine during testing. When I blocked my IP address specifically, the events log clearly showed repeated hits being blocked - which confirmed the pipeline was working as expected.

Browser DevTools (request headers)

I also checked request headers in Chrome DevTools to sanity check what Cloudflare was seeing, including geolocation signals like the detected country.

Key Gotchas/Points to Consider

1) VPN testing can be pretty misleading

Even when your VPN says you’re browsing from a specific country, Cloudflare may detect the request differently depending on VPN routing, shared IP pools and geolocation mappings. In my case, NordVPN behaviour was slightly unpredictable e.g. selecting one location sometimes surfaced as a different country when inspecting headers!

2) IP blocking is the fastest proof test

If you need a quick and reliable confirmation that Cloudflare security rules are being applied correctly, blocking your own IP address is the clearest test. Once confirmed, that IP rule can be removed straight away.

3) “equals” vs “is in”

Cloudflare’s rule builder provides a few ways to express country matching logic. I initially used “Country is in” but what worked most reliably for me in this case was: Country equals. The nuance between operators can be subtle but the key outcome is using a rule format that consistently applies in real traffic.

4) DNS changes can feel intimidating

It’s completely normal for business owners to feel nervous touching DNS, because the DNS zone may include important records for:

  • • Email delivery (MX records - which in this case I didn't touch)
  • • Platform verification (TXT records)
  • • Other third-party services

5) Hosted platforms and Cloudflare concerns

I’d previously read threads raising concerns about layering Cloudflare in front of hosted ecommerce platforms. In this setup, I didn’t run into any issues once traffic was proxied correctly and rules were configured as expected.

Results

  • ✓ Country-level blocking rules were successfully applied
  • ✓ Unwanted traffic could be filtered out before reaching the storefront
  • ✓ The client gained a simple way to monitor blocked requests via Cloudflare events
  • ✓ Adding new countries in future is quick and low risk

Final Notes

This was a simple but effective security win. It reduced analytics noise, helped protect the site, and gave the client an easy way to extend the setup later if more regions need blocking.