đ 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\_modulewith a MaxMind GeoIP database, returning a444status 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;
}
}
}
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:
- Subscribe to a Threat Feed: You get access to an API that provides a list of IPs.
- Create a Lambda Function: You write a small script (we use Python) that runs on a schedule (e.g., every 15 minutes).
-
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.
-
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.
đ Read the original article on TechResolve.blog
â Support my work
If this article helped you, you can buy me a coffee:

Top comments (0)