Nginx 七式防禦術：從零打造 DDoS 防護堡壘

Prologue: The Gatekeeper’s Awakening

In the world of servers, many know how to build — few know how to defend.

We’ve all been there: it’s 3 AM, mysterious traffic is hammering your server, the error log scrolls like a waterfall, and you’re clutching your laptop, whispering prayers to the ops gods. That’s when it hits you: setting up a server is just the beginning — defending it is the real craft.

This article shares battle-tested techniques for building seven layers of defense with Nginx, keeping your server standing tall against DDoS floods. All configurations are production-proven. Copy, paste, sleep soundly.

Architecture Overview: Reverse Proxy as the First Wall

The architecture is straightforward: Nginx as a reverse proxy, facing the internet on one side and backend application servers on the other.

Internet ──▶ Nginx (Reverse Proxy) ──▶ Backend Services
                                        App-Server-A:8443  (ERP System)
                                        App-Server-B:443   (Website, API, CMS...)
                                        App-Server-C:8443  (Preview Env)

Nginx acts as the gatekeeper — all traffic must pass through it. This position is naturally suited for security filtering.

Move 1: Hide Your Identity — Disable Version Info

The first step of any attack is reconnaissance. If your Nginx is cheerfully announcing “I’m nginx/1.24.0” in every response header, you might as well hang a banner on your wall saying “Please look up vulnerabilities for this version.”

# nginx.conf
server_tokens off;

One line. Done. No more version leaks in HTTP responses or error pages.

Move 2: The Flood Gate — Rate Limiting

This is the core weapon against DDoS. The concept is simple: limit the request rate per IP address.

Global Definition (nginx.conf http block)

# Request rate limit: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=10r/s;

# Connection limit: concurrent connections per IP
limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;

Apply to Each Site (server block)

limit_req zone=req_per_ip burst=20 nodelay;
limit_conn conn_per_ip 50;

Parameter breakdown:

• rate=10r/s — Average 10 requests per second (excess gets queued or dropped)
• burst=20 — Allows short bursts of up to 20 requests (for normal rapid clicking)
• nodelay — Burst requests are served immediately, no queuing
• conn_per_ip 50 — Maximum 50 simultaneous connections per IP

Pro tip: Some sites (like ERP systems) legitimately need higher rates. Override in that site’s server block:

# ERP site: more lenient burst limit
limit_req zone=req_per_ip burst=50 nodelay;

Monitoring Rate-Limited Requests

Rate-limited requests appear in the error log:

limiting requests, excess: 10.xxx by zone "req_per_ip"

Count the most rate-limited IPs:

grep "limiting requests" /var/log/nginx/error.log \
  | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

Move 3: The Steel Helmet — Security Headers

HTTP Security Headers act as browser-side shields. We extract them into a shared snippet for all sites to include:

# /etc/nginx/snippets/security-headers.conf

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Move 4: The Empty Fort — Drop Unknown Requests

This is my personal favorite. When someone connects to your port 443 with a raw IP or unknown domain, Nginx responds with 444 — which means “drop connection, send nothing”:

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    server_name _;

    ssl_certificate /etc/nginx/ssl/dummy.crt;
    ssl_certificate_key /etc/nginx/ssl/dummy.key;

    return 444;
}

Why the dummy certificate? Because SSL handshake happens before server_name matching — you need a certificate to complete the handshake, then immediately disconnect.

Effect: Scanners and botnets probing your ports with raw IPs get nothing but silence. Zero information leaked, zero resources wasted.

Move 5: The Iron Shield — SSL/TLS Hardening

Using free Let’s Encrypt certificates with strict protocol settings:

• TLS 1.2 and 1.3 only (goodbye SSLv3, TLS 1.0, 1.1)
• Mozilla-recommended cipher suites
• DH parameters for stronger key exchange
• HTTP/2 enabled for performance

server {
    listen 443 ssl;
    http2 on;

    ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    # ... other configurations
}

Move 6: Anti-Slowloris — Timeout the Cheaters

Slowloris is a low-bandwidth attack: the attacker opens many connections but sends headers extremely slowly, tying up server workers. The countermeasure is strict timeout and buffer limits:

# nginx.conf — global connection limits

client_body_timeout 10s;       # Body read timeout
client_header_timeout 10s;     # Header read timeout
keepalive_timeout 15s;         # Keep-alive timeout
client_body_buffer_size 16k;   # Body buffer size
client_header_buffer_size 1k;  # Header buffer size
large_client_header_buffers 4 8k;

# Per-site proxy timeouts

proxy_connect_timeout 30;
proxy_send_timeout 120;
proxy_read_timeout 120;
send_timeout 30;

Logic: If you can’t finish sending your headers in 10 seconds, you’re probably not a real user. Bye.

Move 7: The Seal — Hidden File Protection

The final line of defense — block access to all hidden files:

location ~ /\. {
    deny all;
}

This prevents access to sensitive files like .git, .env, and .htaccess. Trust me, you don’t want the whole world reading your .env.

Complete Site Configuration Template

Combining all seven moves, a complete site configuration looks like this:

server {
    listen 80;
    listen [::]:80;
    server_name your-domain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    http2 on;
    server_name your-domain.com;

    ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    client_max_body_size 100M;
    proxy_connect_timeout 30;
    proxy_send_timeout 120;
    proxy_read_timeout 120;
    send_timeout 30;

    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    include /etc/nginx/snippets/security-headers.conf;
    limit_req zone=req_per_ip burst=20 nodelay;
    limit_conn conn_per_ip 50;

    location ~ /\. {
        deny all;
    }

    location / {
        proxy_pass https://backend-server:port;
    }
}

Ray Lee’s Verdict

Ray Lee writes: “I have observed the DDoS attacks of this world — they come like floods, and those who accept all comers shall surely fall. But the Seven Moves of Nginx — hiding version to conceal form, limiting rate to stem the flood, adding headers to shield the body, deploying the empty fort to refuse intruders, forging the iron shield to harden walls, timing out cheaters to sever deceit, sealing hidden files to eliminate vulnerabilities — when these seven become one, though ten million requests come, I shall stand.”

Remember: there is no absolutely secure system — only continuously evolving defense. Regularly check your logs, update your configurations, and stay informed on security advisories. That is the way of lasting protection.

May your server never wake you at 3 AM.