adminNginx Rate Limiting Defense Checklist for Website Attacks
Rate limiting helps reduce abusive request bursts against login pages, APIs, search endpoints, webhooks and expensive dynamic pages. It should be used carefully so real users are not blocked by mistake.
Core principle
Rate limiting is not a complete security system. It is a pressure control layer that slows abusive patterns before they overload PHP, WordPress, database or automation workflows.
Checklist
- Identify the endpoint receiving abusive traffic.
- Confirm request volume from access logs.
- Separate normal users from abusive patterns.
- Choose a conservative rate limit.
- Apply rate limiting only to targeted locations first.
- Test with real browser behavior.
- Check Nginx config syntax.
- Reload Nginx safely.
- Monitor 429 responses and user complaints.
- Adjust limits based on evidence.
Reusable lesson
This applies to wp-login.php, XML-RPC, checkout pages, search pages, APIs, webhooks and automation endpoints.
When to Use This Checklist
Use this checklist when a website or webhook endpoint receives repeated abusive requests that increase CPU, PHP-FPM or database load.
Required Tools
SSH access, Nginx config, access logs, error logs, test browser, backup of server block
Before You Start
Do not apply aggressive global rate limits before understanding normal traffic behavior.
Structured Checklist Steps
- Identify target endpoint.
- Confirm volume in logs.
- Separate normal and abusive patterns.
- Choose conservative limit.
- Apply to targeted location.
- Test real behavior.
- Run nginx -t.
- Reload Nginx.
- Monitor 429 responses.
- Adjust based on evidence.
Verification Steps
- Abusive request volume is reduced.
- Normal users can still access the site.
- Nginx config test passes.
- PHP-FPM load decreases if related.
- Logs show expected rate-limit behavior.
Rollback Plan
If rate limiting blocks legitimate users, restore the previous server block and reapply a narrower rule to the specific abusive endpoint.
Common Mistakes
- Applying rate limits globally too early.
- No access log evidence.
- Blocking real users.
- Reloading Nginx without testing config.
- Using rate limit instead of fixing expensive backend logic.
Related Commands
sudo grep "wp-login.php" /var/log/nginx/access.log | tail -n 50
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
sudo nginx -t
sudo systemctl reload nginx
sudo tail -n 100 /var/log/nginx/error.log