Defending Hong Kong cloud servers against malicious requests often requires more than a single line of defense. Attackers might bypass rate limits by launching low-frequency requests from a vast array of distributed IPs, or they might saturate connection limits by launching high-frequency CC (Challenge Collapsar) attacks from a small number of IPs. A truly effective strategy involves chaining together three distinct mechanisms: Nginx acting as the first gatekeeper at the application layer, security groups or firewalls providing hard blocking at the network layer, and Fail2ban establishing a closed-loop system for automated, log-driven banning. Each component handles a specific stage while complementing the others.

　　Layer 1: Nginx Rate Limiting

　　Nginx’s built-in `limit_req` and `limit_conn` modules offer the most direct methods for rate limiting at the application layer.

　　Request rate limiting addresses the issue of a single IP making excessive requests within a given timeframe. The core configuration involves two steps: first, defining the rate-limiting zone within the `http` block, and then applying it within the `location` block.

http {
    # Rate-limit based on client IP using 10MB of shared memory, with the rate set to 5 requests per second.
    limit_req_zone $binary_remote_addr zone=req_zone:10m rate=5r/s;

    server {
        location / {
            # burst=10：Allows a sudden burst of 10 queued requests.
            # nodelay：Burst requests are processed immediately, without additional latency.
            limit_req zone=req_zone burst=10 nodelay;
        }
    }
}

　　The `burst` parameter is crucial. If you set only `rate=5r/s` without specifying `burst`, a user refreshing the page and triggering six requests would see the sixth one immediately rejected, resulting in a poor user experience. By adding `burst=10`, excess requests are queued for a brief period instead of triggering an immediate error.

　　Limiting the number of concurrent connections addresses the issue of a single IP occupying too many connections simultaneously; this is particularly useful for sites—such as download or image hosting sites—that are frequent targets of multi-threaded downloading tools:

http {
    limit_conn_zone $binary_remote_addr zone=conn_zone:10m;

    server {
        location /download/ {
            # Each IP can maintain a maximum of 5 simultaneous connections.
            limit_conn conn_zone 5;
        }
    }
}

　　A common pitfall: If your Hong Kong server sits behind a CDN or reverse proxy, `$binary_remote_addr` captures the CDN node's IP rather than the actual user's IP. Consequently, rate limiting effectively applies to the CDN node, defeating the intended purpose. The correct approach is to use `$http_x_forwarded_for` or configure the `real_ip` module to retrieve the genuine client IP.

　　Layer 2: Security Groups and Firewall Blacklists

　　Nginx rate limiting acts as a "soft limit," returning a 503 error when thresholds are exceeded. However, for known malicious IPs, a more thorough approach is to block them directly at the network layer, preventing them from ever reaching Nginx.

　　Cloud platform security groups serve as the first line of defense. Log in to your Hong Kong cloud provider's console, add a "Deny" rule to the inbound security group settings, and specify the IP address or range you wish to block. A key point to note regarding security group configuration is to avoid overly broad network ranges. For instance, if you only intend to block two attacking IPs, specifying a source like `172.21.10.0/24` would inadvertently block the entire subnet; specifying the exact IPs is safer.

　　The system firewall acts as the second line of defense. If your server runs `firewalld` or `ufw`, you can use "rich rules" to directly reject traffic from specific sources:

# firewalld 封禁单个IP
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="123.45.67.89" reject'
sudo firewall-cmd --reload

　　The relationship between security groups and system firewalls is one of "two independent layers of filtering," meaning both must be configured. Modifying only the security group without adjusting the system firewall—or vice versa—can leave security gaps.

　　Layer 3: Fail2ban – Automated Blocking via Log Analysis

　　Manually adding entries to a blacklist is suitable for dealing with known, static sources of attacks. However, Hong Kong-based servers are subjected to frequent daily scanning and probing attempts, making it impractical to manually block individual IP addresses one by one. Fail2ban provides value by automating the processes of monitoring logs and blocking IPs.

　　Fail2ban operates on a straightforward principle: it continuously monitors log files and uses regular expressions to identify "suspicious behavior." When a specific IP address triggers a violation beyond a set threshold within a defined time window, the tool automatically invokes the firewall to block that IP.

　　Configuration to counter SSH brute-force attacks is the most fundamental use case; simply add the following to `/etc/fail2ban/jail.local`:

[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log
maxretry = 5
findtime = 600
bantime = 86400

　　This means that five failed login attempts within 10 minutes result in a 24-hour ban. It is important to set a longer ban time; short bans (such as 10 minutes) offer little deterrent against automated attack scripts, as they simply wait a short while before trying again.

　　Coordinated defense against malicious Nginx requests is particularly important for Hong Kong cloud servers. Fail2ban can monitor Nginx's `access.log` or `error.log` to identify frequent 401, 403, or 404 errors, or anomalous access patterns targeting specific URLs:

[nginx-limit-req]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 5
bantime = 3600

　　If Nginx returns a 503 error due to `limit_req` or a rate-limiting status due to `limit_conn`, these events are logged in the `error.log`. Fail2ban detects these entries and immediately bans the source IP for one hour. This creates a closed-loop system: Nginx performs the initial filtering, while Fail2ban blacklists IPs that repeatedly trigger limits, preventing subsequent requests from even reaching Nginx.

　　You must configure a whitelist. Add your company's office IP, monitoring system IPs, and your own frequently used IPs to the `ignoreip` list; otherwise, you might accidentally get yourself banned while debugging or performing routine work.

　　A practical troubleshooting step

　　If you suspect your server is being subjected to malicious requests, start by tallying requests by IP address in the Nginx `access.log`:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

　　This command lists the top 20 IP addresses by request volume. If an IP address shows a request count far exceeding that of a normal user, add it to the security group blacklist or manually ban it using Fail2ban:

fail2ban-client set nginx-limit-req banip 123.45.67.89

　　For Hong Kong cloud servers, protection against malicious requests relies on a three-pronged approach: Nginx rate limiting manages request frequency, security groups handle known blacklists, and Fail2ban manages dynamic blocking. When used together, these measures can effectively mitigate most CC attacks and high-volume scraping traffic. However, it is important to note that if the attack traffic itself exceeds the server's bandwidth capacity—such as in the case of a DDoS attack reaching hundreds of Gbps—these methods will be ineffective; instead, cloud-based traffic scrubbing or high-DDoS-protection IP services would be required.