DEV Community

Cover image for Solved: Is there a way to completely block off chinese website visitors?
Darian Vance
Darian Vance

Posted on • Originally published at wp.me

Solved: Is there a way to completely block off chinese website visitors?

🚀 Executive Summary

TL;DR: Website operators frequently encounter resource-wasting and log-polluting traffic, primarily from automated scanners originating from China. This guide outlines three practical methods to effectively block such geo-located visitors, ranging from simple CDN/WAF rules to robust infrastructure-level solutions, to enhance operational hygiene. Solutions include Cloudflare’s UI-based geo-blocking, Nginx GeoIP module for server-level control, and advanced IP reputation blocking using AWS WAF with automated threat intelligence feeds.

🎯 Key Takeaways

  • Cloudflare and similar WAFs offer a quick, UI-driven method to block traffic by country at the edge, preventing requests from reaching origin servers.
  • Nginx can implement server-level geo-blocking using the ngx\_http\_geoip2\_module with a MaxMind GeoIP database, returning a 444 status for blocked requests.
  • For sophisticated threats, a ‘nuclear option’ involves integrating AWS WAF with commercial threat intelligence feeds via a scheduled Lambda function to dynamically update IP sets and block known malicious actors regardless of their origin.

Tired of irrelevant traffic from China lighting up your servers? Learn three practical methods, from a quick UI fix in Cloudflare to robust infrastructure-level blocking with Nginx and AWS WAF, to effectively block unwanted geo-located visitors and reduce server noise.

So, You Want to Block China? A Senior Engineer’s Guide to Geo-Fencing.

I remember a 3 AM PagerDuty alert like it was yesterday. A junior engineer, bless his heart, was in a full-blown panic. “Darian, we’re under attack! The login endpoint on auth-service-prod-01 is getting hammered!” I rolled out of bed, grabbed my laptop, and SSH’d in. The traffic charts were spiky, sure, but the requests-per-second weren’t DDoS-level. Tailing the logs, I saw it plain as day: a slow, methodical, distributed scan for old struts vulnerabilities, originating from a few hundred IPs all resolving to the same Chinese telecom. It wasn’t an attack; it was background noise. Annoying, resource-wasting, log-polluting noise. We’ve all been there. You run a service for a local market, yet your logs are 90% probes from IPs you’ll never do business with.

First, Let’s Talk “Why”

Before we jump into the fix, let’s get one thing straight. This isn’t about people. This is about bots. The vast majority of this traffic is automated scanners, scrapers, and vulnerability probes. They’re looking for low-hanging fruit: outdated WordPress plugins, unpatched Log4j instances, open admin panels, you name it. This traffic does three things, none of them good:

  • Wastes Resources: Every bogus request consumes CPU, memory, and bandwidth. It’s a death by a thousand cuts.
  • Pollutes Logs: It makes it infinitely harder to spot a real, targeted attack when your logs are flooded with scanner noise.
  • Creates False Alarms: Like the one that woke me up at 3 AM, it triggers monitoring alerts and burns out your on-call team.

So, the goal here isn’t malicious; it’s pragmatic. It’s about operational hygiene. Let’s clean up the noise so we can focus on the real signals.

Solution 1: The Quick & Easy (The Cloudflare Fix)

If you’re already using a CDN or a WAF (Web Application Firewall) like Cloudflare, this is a five-minute job. This is the first place I’d go. It’s simple, effective, and doesn’t require you to touch a single line of code or config on your servers.

You essentially just go into your dashboard and create a firewall rule. It looks something like this:

Rule Name: Block China Traffic

Field: Country

Operator: is in

Value: China

Action: Block

And that’s it. You hit ‘Deploy’ and within 30 seconds, requests originating from IPs Cloudflare identifies as Chinese are blocked at the edge, before they ever get a chance to sniff your origin server. It’s beautiful in its simplicity.

Pro Tip: Most modern WAFs (AWS WAF, Google Cloud Armor, Akamai) have a similar point-and-click geo-blocking feature. If you’re paying for one, you should be using it.

Solution 2: The “I Manage My Own Stack” Fix (Nginx GeoIP)

Maybe you’re not on Cloudflare. Maybe you like to run your own metal or manage your own load balancers. I get it. In that case, you handle this at the web server level. For us, that’s usually Nginx. The tool for the job is the ngx_http_geoip2_module.

First, you’ll need to install the module and get a GeoIP database from a provider like MaxMind. Once that’s set up, you add a bit of logic to your nginx.conf.

Here’s a simplified but realistic example of what your config might look like:

http {
    # Define the path to your GeoIP database
    geoip2 /etc/nginx/geoip/GeoLite2-Country.mmdb {
        $geoip2_data_country_iso_code country iso_code;
    }

    # Create a map to check the country code
    # $is_blocked will be 1 if the country is CN, 0 otherwise
    map $geoip2_data_country_iso_code $is_blocked {
        default 0;
        CN 1;
    }

    server {
        listen 80;
        server_name your-awesome-app.com;

        # The actual block logic
        if ($is_blocked) {
            # Return a 444, which closes the connection without a response
            # It's cleaner and more efficient than a 403 Forbidden
            return 444;
        }

        # ... your normal server location blocks go here
        location / {
            proxy_pass http://app_backend;
        }
    }
}
Enter fullscreen mode Exit fullscreen mode

This approach is solid. It’s robust, extremely fast, and stops the request right at the front door (prod-web-01 in our stack) before it ever touches your application code. The downside is that you have to maintain the GeoIP database and keep it updated.

Solution 3: The “No More Mr. Nice Guy” Nuclear Option

Sometimes, just blocking a country code isn’t enough. Attackers use VPNs and proxy networks that span the globe. The *origin* might be China, but the IP could be coming from a compromised server in Germany or a residential proxy in Brazil. In these high-stakes scenarios, we move from geo-blocking to IP reputation blocking.

This involves subscribing to a commercial threat intelligence feed (like Spamhaus, Proofpoint, etc.) that provides constantly updated lists of known malicious IPs, botnets, and anonymous proxies. You then automate the process of feeding this list into your firewall.

Here’s a conceptual breakdown using AWS WAF as an example:

  1. Subscribe to a Threat Feed: You get access to an API that provides a list of IPs.
  2. Create a Lambda Function: You write a small script (we use Python) that runs on a schedule (e.g., every 15 minutes).
  3. The Script’s Job:
    • Fetch the latest IP list from the threat feed API.
    • Compare it to the current IPs in your AWS WAF IP Set.
    • Update the IP Set with any new malicious IPs and remove any that are no longer listed.
  4. The WAF Rule: You have a simple rule in your Web ACL that says “If a request’s source IP is in my BadActorIPSet, then Block.”

This is the most complex solution, but it’s also the most effective against sophisticated, distributed threats. It’s no longer about *where* the request is from, but *who* it’s from. You’re blocking known bad actors, regardless of their location.

Warning: Be careful with this method. Overly aggressive blocklists can sometimes include legitimate CIDR ranges, like a cloud provider’s egress IPs. Test thoroughly and ensure you have a clear process for whitelisting if a legitimate user gets blocked.

So, Which One Is Right For You?

As always, it depends. Here’s my rule of thumb for mentoring my team:

If you are… …then you should…
A small team or startup already using a CDN/WAF. Use Solution 1. It’s fast, free (usually), and good enough.
Managing your own infrastructure and comfortable with server configs. Use Solution 2. It’s powerful and gives you full control.
Protecting a high-value target or just plain sick of the noise. Use Solution 3. It’s more work but the most comprehensive.

At the end of the day, managing unwanted traffic is just another part of running a stable and secure system. Don’t let the noise drown out the signal. Pick a solution, implement it, and enjoy the peace and quiet of cleaner logs.


Darian Vance

👉 Read the original article on TechResolve.blog


☕ Support my work

If this article helped you, you can buy me a coffee:

👉 https://buymeacoffee.com/darianvance

Top comments (0)