Blocking Bot Traffic with Nginx 444 Status Code: Real Config Examples

One morning I woke up to an "abnormal traffic" warning from Hetzner. When I checked the server, there was a bot army sending 400+ requests per second. We were behind Cloudflare, but some bots had reached the origin IP directly. That day I discovered Nginx's 444 status code, and server load dropped by 73%. I've had this config block on every production server for three years.

Most developers return 403 or 503. The problem is: Nginx still prepares a full HTTP response, writes headers, and closes the connection properly. 444, on the other hand, cuts the TCP connection without sending any response. It's a timeout for the bot, zero cost for the server. In this article, I'll share the real configs I use on doktorbul.com and diolivo.com.tr, along with three years of observations.

What is Nginx 444 Status Code and Why It Matters

Nginx 444 is a special code not in the RFC standard. It appears in Nginx documentation as "connection closed without response." It completely bypasses the normal HTTP response cycle:

• 403 Forbidden: Nginx prepares a full HTTP response (header + body)
• 503 Service Unavailable: Same, full response
• 444: Sends TCP FIN packet, no HTTP data at all

I first tested this on kamupersonelhaber.com. There were 50,000+ bot requests per day, most searching for WordPress paths like /wp-login.php and /xmlrpc.php. Our site is static HTML, but bots didn't care. After adding the 444 block:

• CPU usage: 45% → 12%
• Nginx worker memory: 180MB → 65MB
• Access log size: 2.3GB daily → 890MB

The difference is especially significant during DDoS attacks. The bot times out without waiting for a response and has to open a new connection. Combined with rate limiting, the attacker's cost multiplies.

Basic 444 Block: User-Agent Control

The simplest use is blocking known bad bots. Here's the config I use on doktorbul.com:

map $http_user_agent $bad_bot {
    default 0;
    ~*MJ12bot 1;
    ~*AhrefsBot 1;
    ~*SemrushBot 1;
    ~*DotBot 1;
    ~*Baiduspider 1;
    ~*ZoominfoBot 1;
    ~*PetalBot 1;
    ~*python-requests 1;
    ~*Go-http-client 1;
    ~*curl 1;
}

server {
    listen 80;
    server_name doktorbul.com;

    if ($bad_bot) {
        return 444;
    }

    location / {
        proxy_pass http://backend;
    }
}

Points to note in this config:

• map block must be in http context, outside server
• ~* means case-insensitive regex
• if ($bad_bot) is checked on every request, minimal performance cost

AhrefsBot and SemrushBot are controversial. I don't allow SEO tools because doktorbul.com has 79,000 profiles, and every bot crawl was straining the server. If you want SEO analysis, allow it in robots.txt and remove from 444.

Real-World User-Agent List

Bad bot list I've collected over three years:

• Scrapers: MJ12bot, DotBot, BLEXBot, DataForSeoBot
• Fake crawlers: Bytespider, PetalBot (Huawei), YandexBot (unnecessary outside Russia)
• Generic tools: python-requests, Go-http-client, Java/1.x, curl, wget
• Aggressive SEO: AhrefsBot (10,000+ requests daily), SemrushBot
• Spam: MegaIndex, AspiegelBot, BrandVerity

Important: NEVER block legitimate bots like Googlebot, Bingbot, facebookexternalhit. If you see "crawl error" in Google Search Console, it's an SEO disaster.

Path-Based Blocks: WordPress and Admin Panels

Italyanmutfagi.com uses WordPress. There are 618 automatically generated recipes, but bots constantly try /wp-admin/ and /xmlrpc.php. We use static cache, these paths don't exist anyway, but Nginx still processes them. Solution:

location ~* /(wp-admin|wp-login\.php|xmlrpc\.php) {
    return 444;
}

location ~* \.(env|git|svn|htaccess|htpasswd) {
    return 444;
}

location ~* /(phpmyadmin|pma|admin|administrator) {
    return 444;
}

In this config, we're blocking three different threats:

1. WordPress: wp-admin, wp-login.php, xmlrpc.php (brute force target) 2. Sensitive files: .env, .git, .htaccess (information leakage) 3. Generic admin: /admin, /phpmyadmin (automatic scanners)

Note: If you actually need WordPress admin access, add IP whitelist:

location ~* /wp-admin {
    allow 85.123.45.67;  # Your office IP
    allow 10.0.0.0/8;    # VPN pool
    deny all;
    return 444;
}

On italyanmutfagi.com, I moved admin to a completely different subdomain (yonetim.italyanmutfagi.com), so there are no WordPress paths on the public site.

Geo-Blocking: Country-Based Blocking

Diolivo.com.tr sells to Turkey. 98% of traffic from China, Russia, Ukraine is bots. Blocking with GeoIP module makes sense:

# In http block inside nginx.conf
geoip2 /usr/share/GeoIP/GeoLite2-Country.mmdb {
    $geoip2_data_country_code country iso_code;
}

map $geoip2_data_country_code $blocked_country {
    default 0;
    CN 1;  # China
    RU 1;  # Russia
    UA 1;  # Ukraine
    IN 1;  # India (aggressive scrapers)
    VN 1;  # Vietnam
}

server {
    listen 80;
    server_name diolivo.com.tr;

    if ($blocked_country) {
        return 444;
    }

    location / {
        proxy_pass http://woocommerce;
    }
}

GeoIP2 installation (Ubuntu/Debian):

sudo apt install libnginx-mod-http-geoip2
sudo mkdir -p /usr/share/GeoIP
cd /usr/share/GeoIP
sudo wget https://git.io/GeoLite2-Country.mmdb

On Diolivo, this config blocked 12,000+ unnecessary requests daily. Especially bots from China were spamming the checkout page, and the server was consuming 2GB+ RAM for WooCommerce sessions. After geo-blocking, RAM usage dropped by 40%.

Points to Consider

When geo-blocking:

• You might block VPN users (especially US IPs)
• If you're behind a CDN, you don't see the origin IP (check X-Forwarded-For header)
• GeoLite2 database should be updated monthly (MaxMind license now required)

On projects where I use Cloudflare, I do geo-blocking in Cloudflare Firewall Rules, it's more reliable.

Rate Limiting with 444 Combination

Memuratamalari.com has 40,400 organic searches daily. Some bots send 50+ requests per second, normal users make maximum 5-10 requests. Rate limit + 444 combination:

# In http block
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=strict:10m rate=2r/s;

server {
    listen 80;
    server_name memuratamalari.com;

    location / {
        limit_req zone=general burst=20 nodelay;
        limit_req_status 444;
        proxy_pass http://backend;
    }

    location ~* \.(jpg|jpeg|png|gif|css|js|woff2) {
        limit_req zone=general burst=50 nodelay;
        limit_req_status 444;
        expires 30d;
        proxy_pass http://backend;
    }

    location /api/ {
        limit_req zone=strict burst=5 nodelay;
        limit_req_status 444;
        proxy_pass http://api_backend;
    }
}

In this config:

• rate=10r/s: 10 requests per second (per IP)
• burst=20: Queues up to 20 requests
• nodelay: Process queued requests immediately (otherwise user waits)
• limit_req_status 444: Return 444 on limit exceeded (default 503)

On memuratamalari.com, API endpoints are stricter (2r/s), static files are looser (50 burst). When a bot sends 100 requests per second, the first 30 requests pass, the rest are cut with 444.

Rate Limit Calculation

To find the right rate limit value:

1. Analyze Nginx access log: awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20 2. Look at the most active IPs, distinguish legitimate users from bots 3. Find the legitimate user's maximum requests (usually 5-15 req/s) 4. Set rate limit to 2x this value (safety margin)

On doktorbul.com, I initially set 5r/s, legitimate users complained (8-10 requests were going during search). I increased to 10r/s, problem solved.

Referrer and Empty User-Agent Control

Most bots don't send Referer header or put fake domains. Empty User-Agent is also suspicious:

map $http_referer $bad_referer {
    default 0;
    "~*semalt.com" 1;
    "~*buttons-for-website.com" 1;
    "~*free-share-buttons.com" 1;
    "~*casino" 1;
    "~*viagra" 1;
    "~*porn" 1;
}

map $http_user_agent $empty_ua {
    default 0;
    "" 1;
    "-" 1;
}

server {
    listen 80;
    server_name example.com;

    if ($bad_referer) {
        return 444;
    }

    if ($empty_ua) {
        return 444;
    }

    location / {
        proxy_pass http://backend;
    }
}

Semalt.com and buttons-for-website.com are spam referrers, polluting Google Analytics. Empty User-Agent is usually curl or script.

Note: Some monitoring tools (UptimeRobot, Pingdom) send empty UA. Add them to IP whitelist:

geo $monitoring_ip {
    default 0;
    46.137.190.132 1;  # UptimeRobot
    52.89.255.102 1;   # Pingdom
}

server {
    if ($monitoring_ip = 0) {
        if ($empty_ua) {
            return 444;
        }
    }
}

Production Config: Complete Structure I Use on FUTIA Servers

Here's the real, tested config I use on futia.net and client projects. Put it in a single /etc/nginx/conf.d/security.conf file:

# GeoIP2 module
geoip2 /usr/share/GeoIP/GeoLite2-Country.mmdb {
    $geoip2_data_country_code country iso_code;
}

# Rate limit zones
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=static:10m rate=50r/s;

# Bad bot map
map $http_user_agent $bad_bot {
    default 0;
    ~*MJ12bot 1;
    ~*AhrefsBot 1;
    ~*SemrushBot 1;
    ~*DotBot 1;
    ~*Baiduspider 1;
    ~*ZoominfoBot 1;
    ~*PetalBot 1;
    ~*python-requests 1;
    ~*Go-http-client 1;
    ~*curl 1;
    ~*wget 1;
    ~*Bytespider 1;
    ~*DataForSeoBot 1;
    ~*BLEXBot 1;
    "" 1;
    "-" 1;
}

# Bad referer map
map $http_referer $bad_referer {
    default 0;
    ~*semalt.com 1;
    ~*buttons-for-website.com 1;
    ~*free-share-buttons.com 1;
    ~*casino 1;
    ~*viagra 1;
    ~*porn 1;
}

# Geo-block map (optional)
map $geoip2_data_country_code $blocked_country {
    default 0;
    CN 1;
    RU 1;
    # Other countries...
}

# Monitoring IP whitelist
geo $monitoring_ip {
    default 0;
    46.137.190.132 1;  # UptimeRobot
    52.89.255.102 1;   # Pingdom
    # Your own IPs
}

Then in the server block:

server {
    listen 80;
    server_name example.com;

    # Exclude monitoring IPs from checks
    set $block 0;
    if ($monitoring_ip = 0) {
        set $block 1;
    }

    # Bot control
    if ($bad_bot) {
        set $block "${block}1";
    }
    if ($block = "011") {
        return 444;
    }

    # Referer control
    if ($bad_referer) {
        return 444;
    }

    # Geo-block (optional)
    if ($blocked_country) {
        return 444;
    }

    # Sensitive paths
    location ~* /(wp-admin|wp-login\.php|xmlrpc\.php|phpmyadmin|pma) {
        return 444;
    }

    location ~* \.(env|git|svn|htaccess|htpasswd|sql|zip|tar\.gz)$ {
        return 444;
    }

    # Main page
    location / {
        limit_req zone=general burst=20 nodelay;
        limit_req_status 444;
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # API endpoints
    location /api/ {
        limit_req zone=api burst=10 nodelay;
        limit_req_status 444;
        proxy_pass http://api_backend;
    }

    # Static files
    location ~* \.(jpg|jpeg|png|gif|css|js|woff2|svg|ico)$ {
        limit_req zone=static burst=100 nodelay;
        limit_req_status 444;
        expires 30d;
        add_header Cache-Control "public, immutable";
        proxy_pass http://backend;
    }
}

I use this config on doktorbul.com, diolivo.com.tr, and memuratamalari.com. I haven't seen a serious attack in three years, server load is low.

Log Analysis: Monitoring 444 Blocks

To see 444 requests in Nginx access log:

# 444 status code in last 1000 lines
tail -n 1000 /var/log/nginx/access.log | grep " 444 "

# IPs receiving most 444s
grep " 444 " /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Which paths are getting 444
grep " 444 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn

# Which User-Agents are getting 444
grep " 444 " /var/log/nginx/access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn

I run these commands every morning, if I see new bot patterns, I add them to the config. For example, last month I discovered a new bot called "DataForSeoBot", it was sending 8,000+ requests daily. I added it to the map, problem solved.

Monitoring with Prometheus

For more professional monitoring, use nginx-prometheus-exporter:

# Inside nginx.conf
server {
    listen 9113;
    location /metrics {
        stub_status;
    }
}

Prometheus query:

rate(nginx_http_requests_total{status="444"}[5m])

I have a Grafana dashboard on the futia.net server, monitoring 444 rate. If I see a sudden increase, it means there's an attack.

Performance Impact: 444 vs 403 vs 503

My own tests (Hetzner CPX31, 4 vCPU, 8GB RAM):

10,000 requests with Apache Bench:

• 200 OK (normal response): CPU 45%, RAM 320MB, time 12.3s
• 403 Forbidden: CPU 38%, RAM 280MB, time 11.1s
• 503 Service Unavailable: CPU 40%, RAM 290MB, time 11.4s
• 444 (connection close): CPU 8%, RAM 95MB, time 8.7s

444 wins by far. RAM usage is especially critical, because Nginx allocates buffer for each HTTP response. With 444, there's no buffer, just TCP FIN.

Real Case: Diolivo.com.tr DDoS Attack

In March 2024, diolivo.com.tr was DDoS attacked. 1,200+ requests per second, mostly from Chinese IPs. We were behind Cloudflare, but attackers had found the origin IP (from old DNS records). First 10 minutes the server crashed, returned 503 error.

What I did:

1. Activated geo-blocking (China, Russia, Ukraine) 2. Reduced rate limit from 10r/s to 5r/s 3. 444'd all bot User-Agents 4. Changed origin IP, passed DNS through Cloudflare Proxy

Result: Attack stopped within 15 minutes. Server returned to normal load. Cloudflare Analytics showed 840,000 requests blocked, but they never reached origin.

After this case, I put the same config on all client projects. I no longer share origin IPs with anyone, only Cloudflare and Hetzner know.

If you also have strange traffic increases on your server or suspect a bot attack, you can talk to me. As FUTIA, I provide site + automation + security services to Turkish brands from the Netherlands. You can reach me via WhatsApp: +90 532 491 17 05. Or email: info@futia.net. First analysis is free, I'll look at server logs and give specific config recommendations.