Was Rate Limiting ist, wie sich Fixed Window, Sliding Window, Token Bucket und Leaky Bucket unterscheiden, mit Live-Simulator, Status 429, Retry-After und einem Nginx-Beispiel.
Rate Limiting begrenzt, wie viele Requests ein Besucher, ein Schlüssel oder eine IP-Adresse in einem Zeitraum senden darf. Requests über dem Limit werden abgelehnt, meist mit HTTP-Status 429 Too Many Requests und einem Retry-After-Header, der sagt, wann es erneut versucht werden kann. Es schützt Login-Formulare, Kontaktformulare und APIs vor Fluten und ausufernden Rechnungen.
Die vier gängigen Rate-Limiting-Algorithmen
Wenn deine Website eine Anmeldeseite, ein Kontaktformular, einen Checkout oder eine API hat, die andere Apps aufrufen, wird sie irgendwann jemand bombardieren, versehentlich oder absichtlich. Rate Limiting ist die Regel, die festlegt, wie viel zu viel ist. Unten kannst du per Button Requests senden und zusehen, wie jeder Algorithmus sie annimmt oder ablehnt, und dann eine funktionierende Nginx-Konfiguration kopieren.
RFC 6585 definiert 429 Too Many Requests als Status für einen Client, der in einer bestimmten Zeit zu viele Requests gesendet hat. Die Antwort kann einen Retry-After-Header enthalten, der dem Client sagt, wie lange er warten soll.
Standardmäßig beantwortet das Modul limit_req abgelehnte Requests mit 503. Mit der Direktive limit_req_status kannst du auf 429 umstellen, was die meisten APIs bevorzugen, weil es dem Aufrufer genau sagt, was passiert ist.
Noch nicht. Die Felder RateLimit und RateLimit-Policy stammen aus einem Internet-Draft einer IETF-Arbeitsgruppe, der im Oktober 2026 noch in Arbeit war, daher senden manche Dienste stattdessen ältere X-RateLimit-Header. Betrachte sie als hilfreiche Hinweise.
Ein Token Bucket lässt einen Aufrufer angesparte Tokens in einem Burst ausgeben und pendelt sich dann auf die Nachfüllrate ein. Ein Leaky Bucket glättet den Verkehr zu einem festen Abfluss. Nginx dokumentiert sein Modul limit_req als Leaky-Bucket-Verfahren.
Nein. Es kommt gut mit Missbrauch aus wenigen Quellen zurecht, aber Verkehr, der über Tausende Adressen verteilt ist, braucht zusätzlich Schutz bei deinem Hoster oder CDN. Rate Limiting ist eine Schicht, nicht die ganze Verteidigung.
Das erlaubt jeder IP-Adresse 5 Requests pro Sekunde auf dem Login-Pfad, mit einem sofort bedienten Burst von 10, und beantwortet überzählige Requests mit 429 statt des Standards 503.
Die Zone mit 10m speichert die Zähler. Laut Doku fasst ein Megabyte etwa 16 Tausend Zustände zu je 64 Byte.
Für einen einzelnen Server passt ein Token Bucket in wenige Zeilen. Halte die Zählerstände in einem gemeinsamen Speicher, wenn du mehr als einen Server betreibst.
Jeder Schlüssel bekommt 10 Tokens, die sich mit 1 pro Sekunde auffüllen. Ein abgelehnter Aufruf erhält 429 und ein Retry-After in ganzen Sekunden.
Status 429 mit einem Retry-After von 30 Sekunden.
Jeder Algorithmus erlaubt etwa 5 Requests pro 5 Sekunden (oder einen Bucket mit 5, der sich mit 1 pro Sekunde bewegt). Sende Requests, lass Zeit vergehen und sieh zu, was durchkommt.
Algorithmus
Fixed Window
Sliding Window
Token Bucket
Leaky Bucket
1 Request senden
Burst von {n} senden
1 Sekunde warten
Zurücksetzen
Zeit: {v} s
Erlaubt: {n}
Mit 429 abgelehnt: {n}
Request-Protokoll
t={v}s erlaubt
t={v}s abgelehnt (429)
Noch keine Requests. Drück oben einen Button.
Ein Lehrmodell mit Schritten in ganzen Sekunden. Echte Limiter messen in Millisekunden.
Kostenlos starten · Keine Kreditkarte nötig