Rate Limiting
Rate limiting puts a ceiling on how many requests a single visitor may make in a given time. Go over it and nsin blocks them, or challenges them, until they slow down. It protects login pages from password guessing, search pages from scrapers, and your server from being buried.
When to use it
Section titled “When to use it”- Protect login or sign-up pages from credential stuffing.
- Stop someone scraping your whole catalogue.
- Keep an expensive endpoint (search, export, an API) from being overloaded.
- Take the edge off traffic spikes so the site stays up for everyone else.
Create a rate limit rule
Section titled “Create a rate limit rule”- Go to Rules → Add Rule → Rate Limit.
- Set which addresses it protects — for example
/login. - Set the limit: how many requests, in how many seconds.
- Choose how requests are counted, and what happens on breach (below).
- Save.
How requests are counted
Section titled “How requests are counted”| Counting | What it means |
|---|---|
| Per visitor | Everything from one address counts together against the limit. |
| Per visitor, per address | Each path is counted separately for that visitor. |
Use per visitor to limit overall activity. Use per visitor, per address when a rule covers many endpoints and you don’t want busy use of one to consume the budget for another.
What happens on breach
Section titled “What happens on breach”- Block — further requests are refused until the window passes. Use it when going over the limit means abuse.
- Challenge — the visitor is asked to prove they’re human, and continues normally once they do. Use it when a real person might plausibly hit the limit.
You can also allow a burst: a few extra requests tolerated momentarily above the limit. This stops a page that fires several requests at once from tripping an otherwise sensible limit.
An example
Section titled “An example”Protect login
- Applies to:
/login- Limit: 5 requests per 60 seconds
- Counting: per visitor
- On breach: challenge
Real people log in once or twice. A script trying thousands of passwords hits the wall immediately.
Picking a limit
Section titled “Picking a limit”- Start higher than normal use, then tighten it once you’ve seen real traffic.
- Remember that one page view is often many requests (images, CSS, API calls) — scope the rule to the endpoint you actually mean to protect rather than the whole site.
- People behind one office or mobile network share an address. Very tight site-wide limits catch them together.
Common questions
Section titled “Common questions”Will this block real visitors? Not with a sensible limit scoped to the right paths. If you’re unsure, set the breach action to challenge rather than block — a real person just passes it.
Someone hit the limit by accident. It clears itself when the window passes. Nothing to undo.
Rate limiting or the WAF? Both. The WAF stops attacks; rate limiting controls how often anyone can knock. For traffic you never want at all, use a block rule.
Blocked visitors see nsin’s page.
Give 429 your own page — see
Custom Error Pages.