What does 'burst' mean in each of these configs?

In Nginx, burst is the number of requests that can queue above the steady rate before being rejected (with nodelay, they're processed immediately up to that queue size instead of being delayed). In HAProxy's stick-table approach here, burst sets the request-count threshold measured over a window sized so its average matches your requests-per-second value. In Traefik, burst is the token bucket's capacity, how many requests can arrive at once before the average rate limit kicks in.

Why does nodelay appear in the Nginx config?

Without nodelay, Nginx queues burst requests and releases them at the steady rate, adding latency. With nodelay, burst requests are served immediately (up to the burst size) and only requests beyond that are rejected, which is usually what you want for an API rather than smoothing out a media upload queue.

Why is HAProxy's rate limiting more roundabout than Nginx's?

HAProxy doesn't have a single built-in 'requests per second with burst' directive like Nginx's limit_req; instead you build it from a stick-table tracking per-IP counters plus an http-request deny condition. This tool picks the tracking window so the configured burst and requests-per-second values line up consistently, but it's a composed pattern, not a single directive.

Does Traefik's rateLimit middleware need to be attached to a router to work?

Yes. Defining the middleware alone does nothing; it must be listed under a router's `middlewares` list, as shown in the generated example router, or Traefik will never apply it to incoming requests.

Rate Limiting Config Generator - Nginx, HAProxy, Traefik

Overview

Introduction

Rate limiting is one of the highest-value, lowest-effort protections you can put in front of an API, but Nginx, HAProxy, and Traefik each implement it with a different mental model, a leaky-bucket directive, a stick-table counter, or a token-bucket middleware, so the same 'X requests per second, burst of Y' intent turns into three very different configs.

This tool takes that one intent and generates the matching config for whichever of the three you're running.

What Is Rate Limiting Config Generator?

A generator for request rate limiting across Nginx (limit_req_zone + limit_req with nodelay), HAProxy (a stick-table tracking per-client-IP request rate, paired with an http-request deny rule), and Traefik (the rateLimit middleware's average/burst/period fields, attached to an example router).

All three are driven by the same two inputs, a requests-per-second value and a burst allowance, translated into each platform's native mechanism.

How Rate Limiting Config Generator Works

You set a requests-per-second limit and a burst size, then pick Nginx, HAProxy, or Traefik. The generator validates both numbers are sane before producing output.

For Nginx, it emits a shared-memory zone sized by client IP and a location-level limit_req referencing it. For HAProxy, it derives a stick-table tracking window from the burst-to-rate ratio and emits the tracking and deny rules. For Traefik, it emits a rateLimit middleware with average/burst/period plus an example router attaching it.

When To Use Rate Limiting Config Generator

Use it when protecting a public API or login endpoint from abusive traffic spikes or brute-force attempts at the proxy layer, before it reaches your application.

It's also useful when migrating rate limiting from one proxy to another and you need the equivalent config in the new platform's syntax.

Often used alongside Nginx Reverse Proxy Generator, Load Balancer Config Generator and HAProxy Config Generator.

Features

Advantages

Produces each platform's idiomatic rate-limiting mechanism instead of a lowest-common-denominator approximation.
Includes `limit_req_status 429`/`deny_status 429` so rate-limited clients get a proper HTTP 429, not a generic error.
Derives HAProxy's stick-table window automatically from your rate and burst values instead of requiring you to work out the math by hand.

Limitations

Nginx's shared memory zone size (10m) is a fixed default here; very high-traffic sites tracking millions of distinct IPs may need to size it up manually.
The HAProxy stick-table approach approximates a rate+burst limit via a single counting window; it isn't a true dual-rate (sustained + burst) limiter the way Nginx's or Traefik's token-bucket models are.

Examples

10 req/s with a burst of 20 on Nginx

Input

provider: nginx, requestsPerSecond: 10, burst: 20

Output

http {
    limit_req_zone $binary_remote_addr zone=rl_zone:10m rate=10r/s;

    server {
        location / {
            limit_req zone=rl_zone burst=20 nodelay;
            limit_req_status 429;
        }
    }
}

The zone tracks requests per client IP; burst=20 with nodelay lets up to 20 requests through immediately above the 10r/s steady rate before Nginx starts returning 429s.

Best Practices & Notes

Best Practices

Set the rate limit meaningfully above your legitimate peak per-client traffic, so real users aren't caught by a limit meant for abuse.
Return 429 (not a generic 503/403) so well-behaved clients and libraries can distinguish rate limiting from an outage and back off appropriately.
Apply rate limiting at the proxy layer for cheap, early rejection, but don't treat it as a substitute for authentication or a WAF against more sophisticated abuse.

Developer Notes

Nginx's `limit_req_zone` allocates a shared-memory zone (sized in the `:10m` suffix) that stores a leaky-bucket state per key ($binary_remote_addr here); `nodelay` changes it from queueing-and-delaying excess requests to immediately serving up to `burst` before rejecting. HAProxy's rate limiting is composed from `stick-table` (a generic per-key counter/rate store) plus `http-request deny` conditions, there's no single 'rate limit' directive; the generated window length is chosen as `ceil(burst / requestsPerSecond)` seconds so the configured burst count corresponds to roughly the target average rate. Traefik's `RateLimit` middleware implements a token bucket directly via `average`/`burst`/`period` fields, closer in spirit to Nginx's model than HAProxy's.

Rate Limiting Config Generator Use Cases

Protecting a public API endpoint from traffic spikes or scraping
Rate-limiting login/auth endpoints to slow down credential-stuffing attempts
Migrating an existing rate limit policy from one reverse proxy to another

Common Mistakes

Setting burst to 0 or a very small value on Nginx, which makes legitimate simultaneous browser requests (a page loading several assets at once) get rejected.
Forgetting to attach the Traefik rateLimit middleware to a router, so it's defined but never actually applied to any traffic.

Tips

Test the generated limit against your real traffic pattern (including simultaneous asset loads from a single page) before rolling it out, rate limits tuned only against synthetic single-request tests often reject legitimate bursts.

Rate Limiting Config Generator