Product

Product Features How to Compare Docs Screenshots Why

Start here

Getting started Download Guides Frequently asked questions

More

Security Support Roadmap About

Rate and connection limits

10 answers

Capping how fast and how much one visitor can ask for.

Looking for something specific

The searchable index covers all 326 answers at once and filters as you type.

98 Add a rate limit
  1. Zones & Access, Rate limits tab, add one.
  2. Name it something you will recognize, such as login-limit.
  3. Counts by $binary_remote_addr, rate 10r/s, memory 10m.
  4. Save, then choose it on a site or, better, on a path.

A zone that says it is not used yet is doing nothing. Making one is only half the job.

rate limitzonethrottlerequests per second
99 What rate should I set?

Well above what a real person does. Somebody reading a site makes a handful of requests a second while a page loads, so ten a second stops abuse without anybody noticing.

Set it too low and real visitors get errors, which is a worse outage than the one you were protecting against, and harder to spot because most people just leave rather than complaining.

how manyratetoo lowtuning
100 Add a connection limit

Zones & Access, Connection limits tab. Name it, count by $binary_remote_addr, give it 10m of memory, then choose it on a site or path.

Be careful with a low number. A browser opens several connections at once on purpose, so a limit of one or two breaks ordinary visitors. Ten is a gentle starting point.

connection limitslowlorisconcurrent
101 Do limits apply across both nodes?

No. The counters live in nginx shared memory on each box, so they are per node. With two nodes and traffic split between them, a visitor could get up to twice the configured rate in the worst case. Size the limit with that in mind.

per nodeclustersharedcounters
102 Test a rate limit before relying on it

Ask for a page faster than the limit and confirm you get refused, then confirm normal use does not. A limit nobody has tested is a setting, not a protection, and the two look identical right up until they do not.

for i in $(seq 1 40); do curl -s -o /dev/null -w "%{http_code} " https://example.com/login; done
testverifycurl503
175 Let people upload bigger files

Open the site, Settings tab, Limits and Timeouts, and raise Maximum upload size. A request over the limit gets 413 Request Entity Too Large.

Raise Upload timeout at the same time. A 500MB file over a home connection takes several minutes, and the default timeout will cut it off long before it finishes even though the size limit was fine.

Set it on the upload path rather than the whole site where you can. A site wide 500MB limit is an invitation to anybody who wants to fill your disk.

413upload sizeclient_max_body_sizefile uploadtoo large
176 Cap the download speed for big files

Open the site, Settings tab, Rate Limiting, Bandwidth limit per connection. That is per connection, not per visitor, so somebody using four connections gets four times the cap.

Full speed for the first lets the beginning through untouched and then applies the cap. Set it to a few megabytes and small files, pages and images are never slowed at all, while a big download settles into the limit after the first moment.

That combination is what keeps one person pulling a large file from eating the whole line without making the site feel slow for everybody else.

limit_ratebandwidththrottledownload speedlarge files
177 Stop slow connections holding resources open

Open the site, Settings tab, Limits and Timeouts. Four boxes, all doing the same kind of job:

  • Header timeout: how long a client may take to send its request headers. This is the one that stops the classic attack of opening hundreds of connections and sending one byte a minute.
  • Upload timeout: the same for the body.
  • Response send timeout: how long to wait while the client accepts the answer.
  • Keep-alive timeout: how long an idle connection is kept for the next request.

The defaults are already short enough to handle the obvious version of this. Only raise them for a real reason, such as genuinely large uploads, and raise the one that matters rather than all four.

slowlorisslow clienttimeoutconnection exhaustionkeepalive
178 Let a short burst through at full speed

A rate limit of 10 a second does not mean ten every second. It means one every tenth of a second, and a page that pulls twelve images at once has eleven of them refused.

Set Burst allowance to soak that up, then decide what happens to the burst:

  • Serve burst immediately ticked: the burst is answered at once and only what is over it is refused. This is what you want almost always.
  • Unticked: the burst is queued and released at the limit rate. The requests all succeed, but they feel slow.

A burst of 20 with immediate serving is a reasonable starting point for a normal web page.

burstnodelayrate limit503too many requests
179 Change the status code a rate limit returns

Open the site, Settings tab, Rate Limiting, tick Show advanced settings, and set Rate limit status code.

The default is 503, which means the server is unavailable. 429 is more honest, because it says too many requests and clients that understand it will back off and try again rather than treating it as an outage.

Set it to 429 if anything automated talks to this site. Leave it alone if you do not care.

429503too many requestslimit_req_statusretry after

Two fresh servers is all it takes

Ubuntu 22.04 or newer, root access, and about twenty minutes. The installer does the rest and it is safe to run twice.