What does rate limiting protect against?

It caps how many requests a single client can make in a window, which blunts brute-force login attempts, credential stuffing, scraping, accidental client loops, and small abusive traffic spikes before they overwhelm your app or database. It is not full DDoS protection - that needs an upstream edge - but it stops the most common per-client abuse and keeps one bad actor from degrading the service for everyone.

What is burst, and why nodelay?

Real traffic is bursty - a page load fires several requests at once - so a hard per-second limit would reject legitimate users. burst lets a client exceed the steady rate briefly by queuing a number of extra requests. nodelay serves those burst requests immediately instead of spacing them out, which feels normal to users while still rejecting anything beyond the burst. Without nodelay, bursts are throttled with delay rather than served fast.

Should login endpoints have a stricter limit?

Yes. Login and other auth endpoints are the targets of brute-force and credential-stuffing attacks, and legitimate users hit them rarely, so a much tighter limit there (a few requests per minute) shuts down automated guessing without affecting real users. The generator can output a separate, stricter zone for those routes.

Free tool · Runs in your browser

Rate-limit your app.

One bad actor — a brute-force script, a runaway client, a scraper — shouldn't be able to degrade your service for everyone. Set a limit and get an nginx config with burst handling, a 429 response, and an optional strict limiter for login routes.

Allow up to

Burst (brief spikes allowed)

Apply to path

Upstream (your app)

Add a strict limiter for /login (anti brute-force)

One client shouldn't sink the ship

Most outages that look like attacks aren't sophisticated — they're one client in a retry loop, one scraper with no backoff, one brute-force script hammering your login. Without a limit, a single source can saturate your app and database and take the whole service down for everyone else. A few lines of rate-limiting cap each client to something reasonable and turn that from an outage into a handful of 429s.

Rate limiting at the proxy handles the per-client case. The broader picture — noticing the abuse, seeing it across every host, and tightening the response when something coordinated shows up — is the kind of continuous awareness a control plane gives you over the infrastructure you own.

Related free tools

UFW firewall generatorLock down your server SSH hardening generatorLock down sshd_config Security headers checkerGrade your headers Secrets scannerFind leaked secrets

All free tools →

Cap the abuse. See the rest.

Infraveil watches request patterns and abuse signals across the hosts you own, surfaces what a single proxy can’t, and keeps a tamper-evident record of how your edge responded — protection you can inspect, on infrastructure you control.

See how it works

Get the edge-hardening playbook

Rate limits, headers, and proxy hardening for a backend you run yourself. No spam.