Block Bad Bots and Scanners in Nginx

Most unwanted traffic is not sophisticated: scripts probe for .env files, .git directories and admin panels you do not run. Matching those paths at the edge is cheap and rarely blocks a real user.

Match probes, not user agents

User-agent strings are trivial to fake. Requests for paths your site never serves are a more reliable signal.

location ~* ^/(\.env|\.git|wp-login\.php|phpmyadmin) {
    return 444;
}

444 versus 403

Nginx 444 closes the connection without a response, which costs the scanner time and gives no information. Use 403 while testing so you can see what matches.

Open the Bot & scanner blocking generator

Frequently asked questions

Will this block Googlebot?

Not if you only match paths that do not exist on your site. Avoid blocking by broad user-agent patterns.

Guides

• Nginx Reverse Proxy Configuration
• Caddy Reverse Proxy Configuration
• Nginx Static Site Configuration
• Caddy Static Site Configuration
• Nginx + PHP-FPM Configuration
• Caddy + PHP-FPM Configuration
• Nginx SSL/TLS Configuration
• Nginx Load Balancer Configuration
• Caddy Load Balancer Configuration
• Nginx Rate Limiting Configuration
• Nginx Security Headers Configuration
• Caddy Security Headers Configuration
• Nginx Gzip Compression Configuration
• Nginx Caching Configuration
• Caddy HTTPS Redirect Configuration
• Nginx WebSocket Proxy Configuration
• Nginx Content-Security-Policy Header
• Block Bad Bots and Scanners in Nginx
• fail2ban for Nginx
• nginx.conf Best Practices
• Nginx Location Regex Tester
• Deploy Nginx Config with GitHub Actions