In the Nginx configuration, when you want to limit the request processing rate by using the limit_req_zone / limit_req instructions, I don't really understand the use of the nodelay option.
In my understanding, it terminates the requests above the defined rate without delaying them. So it seems equivalent to burst=0. That is why I don't understand the following example :

limit_req zone=one burst=5 nodelay;

burst defines the number of requests which could be delayed, so what is the meaning to define burst if there is the nodelay option?


I find limit_req documentation clear enough.

burst is documented that way:

Excessive requests are delayed until their number exceeds the maximum burst size [...]

nodelay is documented that way:

If delaying of excessive requests while requests are being limited is not desired, the parameter nodelay should be used

Requests are limited to fit the defined rate. If requests are incoming at a higher rate, no more than the defined number of requests per time unit will be served. You then need to decide on what to do with those other requests.

  • By default (no burst, no nodelay), requests are denied with an HTTP 503 error.
  • With burst, you stack the defined number of requests in a waiting queue, but you do not process them quicker than the defined requests per time unit rate.
  • With burst and nodelay, the queue won't be waiting and request bursts will get processed immediately.
  • 3
    Thanks for your clarification, the documentation isn't clear enough for me.
    – Nicolas
    Nov 11 '14 at 21:40
  • 1
    I edited my answer to reflect the documentation by quoting it. Every word is carefully weighted in nginx documentation to make it concise: that is what is nice about it. Nov 12 '14 at 16:48
  • 3
    So what is the difference between limit_req_zone $binary_remote_addr zone=flood:10m rate=6r/s; limit_req zone=flood burst=0; which allows 6 requests per second and limit_req_zone $binary_remote_addr zone=flood:10m rate=1r/s; limit_req zone=flood burst=5 nodelay; which also allows 6 requests per second ?
    – Nicolas
    Nov 13 '14 at 16:23
  • 2
    Just want to confirm about Bernard's anwser. If what Bernard said was correct, With burst and nodelay, the r/s rate of hit the webserver will be more than the defined requests from time to time, right?
    – Jcyrss
    Jan 28 '15 at 9:09
  • 2
    @BernardRosset could you please clarify the "queue won't be waiting" — what do you mean by that? Jul 25 '15 at 11:28

The comments on the original answer seem wrong.

The question at hand is what the difference between, say rate=6r/s burst=0 and rate=1r/s burst=5 nodelay

The answers are great about explaining the difference when the nodelay option is NOT present -- in which case, the requests queue up with the burst, and are 503'd without the burst.

The original answer seems spot on -- with nodelay, the burst requests get processed immediately. And thererfore, the only implication of that is that there is NO difference between specifying a burst + nodelay vs. just specifying a the higher limit with busrt=0 in the first place.

Therefore, to more succinctly answer the OP question: the meaning of burst when nodelay is specified is the same as just specifying a larger rate without burst.

  • Thanks to have clarified this point, which was effectively the reason of my question.
    – Nicolas
    Aug 1 '15 at 10:13
  • This is wrong. Read my answer + comments again. If you still do not see it, let's make sketch: 6r/s on both configurations provided by Nicolas in a comment on my answer. 1st second -> both scenario will serve 6r, but conf #2 will store 5 in burst. 2nd second and onwards, still the same for conf #1 (all 6r served), but conf #2 will have removed 1 from the burst bucket according to a consumption fitting the rate limit, leaving space for 1r in the queue. The other 5r are thrown away. Jan 30 '17 at 14:51
  • @BernardRosset: but with nodelay, won't that mean those requests are processed immediately instead of queued?
    – siride
    Jan 10 '18 at 20:55

With burst and nodelay specified I find it easier to understand the mechanism like this (the other way around than it is usually understood):

  1. You allow a maximum of burst requests. With $binary_remote_addr that's the maximum number of requests that you accept from a given address. Every request increases an internal counter. When the counter reaches burst all additional requests are denied (and the counter is not increased beyond burst value).
  2. This counter is continuously decreased at a rate specified using rate.

This logic suggests that it makes perfect sense to specify a high burst value (e.g. 100 and more) and a low rate value (even something like 2r/s). This handles normal browsing (a batch of parallel requests followed by a quiet period) better while protecting against sustained bot request stream.


Based on the excellent Dan's answer and on the source code of nginx, a concise summary for the nodelay behavior seems to be the following:

  • burst is how many new concurrent requests are allowed.
  • rate is how many new concurrent requests become old per unit of time. (This updating happens gradually: once per request but not per second.)

I asked Nicolas's question to the guy who wrote the below post in nginx website. NGINX Rate limiting.His reply is as below

In the former rate limit, nginx will accept consecutive requests at 1/6th seconds intervals. it will not accept a burst of requests that do not satisfy that minimum time interval. On the other hand in the latter definition, nginx will accept a burst of up to 6 requests regardless of the time interval between requests. Answer link

  • Hello @Gardener and welcome on Server Fault. Thanks for your well crafted contribution. The link to source is very appreciated.
    – Marco
    Nov 6 '19 at 10:56

I'm suggesting to read this thread: limit_req_zone limit by location/proxy

and this answer: stackoverflow

  • 1
    Link-only answers are considered sub-par on Server Fault. Please provide useful content here and then link elsewhere for more detail if needed.
    – EEAA
    May 4 '16 at 12:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.