Was ist IP-Rate-Limiting?

IP-Rate-Limiting ist ein Mechanismus, der die Anzahl der Anfragen begrenzt, die eine IP-Adresse innerhalb eines bestimmten Zeitraums an einen Server senden kann. Wenn Sie das Limit überschreiten, lehnt der Server Ihre Anfragen vorübergehend ab, in der Regel mit einem HTTP-Fehler 429 („Too Many Requests"). Es ist eines der gängigsten Werkzeuge zum Schutz von Servern gegen Missbrauch, Denial-of-Service-Angriffe und automatisiertes Scraping.

Sie sind dem wahrscheinlich schon begegnet, ohne es zu wissen. Wenn eine Website nach mehreren fehlgeschlagenen Anmeldeversuchen „Zu viele Versuche, versuchen Sie es in 5 Minuten erneut" anzeigt, ist das Rate-Limiting. Wenn eine API nach einer bestimmten Anzahl von Aufrufen pro Minute einen Fehler zurückgibt, ist das Rate-Limiting. Wenn eine Suchmaschine Ihre Anfragen vorübergehend blockiert, weil Sie zu schnell gesucht haben, ist das ebenfalls Rate-Limiting.

Warum es notwendig ist

Ein Webserver hat begrenzte Ressourcen: CPU, Arbeitsspeicher, Bandbreite, Datenbankverbindungen. Jede Anfrage verbraucht einen Teil dieser Ressourcen. Ohne jegliche Begrenzung könnte ein einzelner Nutzer (oder ein automatisiertes Skript) den Server monopolisieren, indem er Tausende von Anfragen pro Sekunde sendet, und den Dienst für alle anderen unzugänglich machen.

Rate-Limiting schützt gegen mehrere Arten von Bedrohungen:

DDoS- und Brute-Force-Angriffe. Ein Distributed-Denial-of-Service-Angriff (DDoS) überflutet einen Server mit Anfragen, um ihn unverfügbar zu machen. Rate-Limiting allein reicht nicht aus, um einen massiven DDoS-Angriff zu blockieren (der von Tausenden verschiedener IP-Adressen kommt), aber es begrenzt den Schaden, den eine einzelne IP verursachen kann. Bei Brute-Force-Angriffen (Tausende von Passwörtern ausprobieren) ist Rate-Limiting die erste Verteidigungslinie: Die Begrenzung auf 5 oder 10 Anmeldeversuche pro Minute macht den Angriff unpraktikabel.

Missbräuchliches Scraping und Crawling. Bots, die Website-Inhalte extrahieren (Preise, Artikel, Daten), senden Hunderte von Anfragen pro Sekunde. Rate-Limiting verlangsamt diese Bots so weit, dass eine massenhafte Extraktion wirtschaftlich nicht mehr tragbar ist (zu langsam, zu viel Serverzeit erforderlich).

API-Missbrauch. Öffentliche APIs (Wetter, Geolokalisierung, KI, Zahlungen) haben für den Anbieter Kosten pro Anfrage. Ohne Rate-Limiting könnte ein Nutzer unverhältnismäßig viele Ressourcen verbrauchen, sei es durch einen Fehler (eine Schleife im Code) oder absichtlich. Die meisten APIs setzen Limits pro API-Schlüssel und pro IP-Adresse.

Fairness zwischen Nutzern. Selbst ohne böswillige Absicht kann ein „gieriger" Nutzer (der eine Seite 50-mal pro Minute aktualisiert oder ein schlecht geschriebenes Skript) die Erfahrung für andere verschlechtern. Rate-Limiting gewährleistet eine faire Verteilung der Ressourcen.

Wie es technisch funktioniert

Das Prinzip ist einfach: Der Server ordnet jede Anfrage einer IP-Adresse zu, zählt die Anzahl der von dieser IP in einem Zeitfenster empfangenen Anfragen und lehnt Anfragen ab, die den definierten Schwellenwert überschreiten. Die konkrete Implementierung variiert jedoch je nach verwendetem Algorithmus.

Festes Fenster (Fixed Window). Die Zeit wird in feste Intervalle unterteilt (zum Beispiel Einminutenfenster). Der Server zählt die Anfragen pro IP in jedem Fenster. Erreichen Sie 100 Anfragen im aktuellen Fenster, werden die folgenden bis zum Beginn des nächsten Fensters abgelehnt. Es ist der einfachste Algorithmus, hat aber einen Fehler: Senden Sie 100 Anfragen am Ende eines Fensters und 100 am Anfang des nächsten, haben Sie 200 Anfragen in wenigen Sekunden gesendet, das Doppelte des vorgesehenen Limits.

Gleitendes Fenster (Sliding Window). Statt fester Fenster betrachtet der Server zu jedem Zeitpunkt die letzten N Sekunden. Jede Anfrage wird über einen gleitenden Zeitraum gezählt. Das glättet die Verteilung und beseitigt das Problem des festen Fensters, erfordert aber mehr Speicher und Rechenleistung auf Serverseite.

Token Bucket (Eimer mit Tokens). Jede IP verfügt über einen „Eimer" mit einer festen Anzahl von Tokens. Jede Anfrage verbraucht ein Token. Tokens regenerieren sich mit konstanter Rate (zum Beispiel 10 pro Sekunde). Ist der Eimer leer, wird die Anfrage abgelehnt. Dieses Modell erlaubt kurze Stoßbelastungen (Bursts): Sie können viele Anfragen auf einmal senden, wenn Ihr Eimer voll ist, müssen dann aber auf die Regeneration warten. Es ist der in der Produktion am häufigsten verwendete Algorithmus, weil er sowohl flexibel als auch vorhersehbar ist.

Leaky Bucket (durchlöcherter Eimer). Anfragen treten in eine Warteschlange ein (den Eimer) und werden mit konstanter Rate verarbeitet (die Abflussrate). Ist der Eimer voll, werden neue Anfragen abgelehnt. Im Gegensatz zum Token Bucket erzwingt der Leaky Bucket eine strikt konstante Ausgangsrate ohne Bursts. Er ist nützlich, wenn Sie einen perfekt gleichmäßigen Verarbeitungsfluss wünschen.

Wo Rate-Limiting angewendet wird

Rate-Limiting kann auf verschiedenen Ebenen der Netzwerkinfrastruktur angewendet werden, und in der Praxis ist das oft der Fall: Mehrere Schichten überlagern sich.

Auf Webserver-Ebene. Nginx, Apache und die meisten Webserver integrieren Rate-Limiting-Module. Nginx zum Beispiel verwendet den Leaky-Bucket-Algorithmus mit seiner limit_req-Direktive. Sie definieren eine Anzahl von Anfragen pro Sekunde pro IP, und Nginx erledigt den Rest. Das ist effektiv für einen Grundschutz, aber der Server muss trotzdem jede Anfrage empfangen und teilweise verarbeiten, bevor er sie ablehnt.

Auf Reverse-Proxy- oder Load-Balancer-Ebene. Das Rate-Limiting vor die Anwendungsserver zu setzen (auf einem Reverse Proxy wie Nginx oder HAProxy oder einem Load Balancer) ermöglicht es, Anfragen zu blockieren, bevor sie die Anwendung erreichen. Das ist ressourceneffizienter.

Auf CDN- oder Web Application Firewall (WAF)-Ebene. Dienste wie Cloudflare, AWS WAF oder Akamai wenden Rate-Limiting am Netzwerkrand (Edge) an, bevor die Anfrage überhaupt Ihre Infrastruktur erreicht. Das ist die wirksamste Schicht gegen volumetrische Angriffe, weil die Anfrage so nah wie möglich an ihrer Quelle blockiert wird.

Auf Anwendungsebene. Die Anwendung selbst kann Rate-Limiting implementieren, oft mit mehr Granularität: pro angemeldetem Nutzer, pro Endpunkt, pro Operationstyp. Eine API kann beispielsweise 1.000 GET-Anfragen pro Minute erlauben, aber nur 10 POST-Anfragen auf einem Kontoerstellungsendpunkt, weil missbräuchliche Kontoerstellungsversuche ein häufiger Angriffsvektor sind.

HTTP-Header im Zusammenhang mit Rate-Limiting

Wenn ein Server Rate-Limiting anwendet, kommuniziert er die Limitinformationen in der Regel über HTTP-Header in der Antwort. Es gibt keinen universellen Standard, aber die gängigsten Konventionen sind:

X-RateLimit-Limit: die maximale Anzahl erlaubter Anfragen im aktuellen Zeitfenster. X-RateLimit-Remaining: die Anzahl verbleibender Anfragen vor Erreichen des Limits. X-RateLimit-Reset: der Zeitpunkt (als Unix-Timestamp oder verbleibende Sekunden), zu dem das Fenster zurückgesetzt wird und der Zähler von vorne beginnt. Retry-After: ein Standard-HTTP-Header, der angibt, wie lange man warten soll, bevor man es erneut versucht, zurückgegeben mit der 429-Antwort.

Ein IETF-Entwurf (RFC 6585 für den Statuscode 429 und neuere Vorschläge) versucht, diese Header zu standardisieren, aber in der Praxis verwendet jede API ihre eigene Konvention. Wenn Sie eine Anwendung entwickeln, die APIs konsumiert, lesen Sie immer die API-Dokumentation, um zu erfahren, wie sie ihre Limits kommuniziert.

Warum die IP allein nicht immer ausreicht

IP-basiertes Rate-Limiting hat ein grundlegendes Problem: Eine IP-Adresse entspricht nicht immer einem einzelnen Nutzer.

CGNAT. Viele Mobilfunkanbieter und einige ISPs nutzen CGNAT (Carrier-Grade NAT), bei dem Hunderte oder Tausende von Nutzern eine einzige öffentliche IPv4-Adresse teilen. Begrenzen Sie eine IP auf 100 Anfragen pro Minute, begrenzen Sie in Wirklichkeit alle Nutzer hinter diesem CGNAT auf insgesamt 100 Anfragen. Ein einzelner normaler Nutzer kann das Kontingent für alle anderen erschöpfen.

Unternehmens- und Hochschulnetze. Tausende von Mitarbeitern oder Studierenden können über eine einzige öffentliche IP-Adresse (oder eine kleine Anzahl von Adressen) auf das Internet zugreifen. IP-basiertes Rate-Limiting bestraft sie kollektiv.

VPNs und Proxys. VPN-Nutzer teilen sich oft eine IP-Adresse mit Hunderten anderer Personen. Ein striktes IP-basiertes Rate-Limiting kann legitime Nutzer blockieren, nur weil sie denselben VPN-Server wie ein Bot verwenden.

Dynamische IP-Adressen. Umgekehrt kann ein Angreifer seine IP-Adresse leicht ändern (mit einem Proxy-Pool, einem Botnet oder einfach durch Umschalten des Flugmodus am Telefon) und das IP-basierte Rate-Limiting umgehen. Wenn das Limit pro IP gilt und der Angreifer Zugang zu 10.000 Adressen hat, wird das effektive Limit mit 10.000 multipliziert.

Deshalb kombinieren moderne Rate-Limiting-Systeme die IP in der Regel mit anderen Identifikatoren: API-Schlüssel, Authentifizierungstoken, Browser-Fingerprint, Session-Cookie. Die IP bleibt ein nützliches Kriterium, ist aber selten allein ausreichend.

Was passiert, wenn Sie limitiert werden

Die häufigste Antwort ist ein HTTP-Statuscode 429 (Too Many Requests). Der Server kann auch einen 503 (Service Unavailable) zurückgeben, wenn die Begrenzung auf eine allgemeine Überlastung zurückzuführen ist und nicht auf eine individuelle Überschreitung.

Manche Dienste blockieren den Zugang nicht vollständig, sondern verschlechtern den Service: Sie verlangsamen die Antworten (Throttling), reduzieren die Qualität der Ergebnisse oder fügen ein CAPTCHA hinzu, um zu überprüfen, ob Sie ein Mensch sind.

Andere Dienste blockieren stillschweigend, ohne einen expliziten Fehler zurückzugeben. Sie antworten weiterhin mit Statuscode 200 (OK), liefern aber leere Daten oder verschlechterte Ergebnisse. Dieses „stille Rate-Limiting" (Shadow Banning) ist bei sozialen Netzwerken und einigen Suchmaschinen verbreitet und ist so konzipiert, dass es für Bots schwer zu erkennen ist.

Wie Entwickler mit Rate-Limiting umgehen

Wenn Sie eine Anwendung entwickeln, die eine API konsumiert, müssen Sie Rate-Limiting ordnungsgemäß handhaben. Die Standardmethode ist „Exponential Backoff": Wenn Sie eine 429-Antwort erhalten, warten Sie eine bestimmte Zeit, bevor Sie es erneut versuchen, und verdoppeln diese Zeit bei jedem aufeinanderfolgenden Fehlschlag. Zum Beispiel: erster Versuch nach 1 Sekunde, zweiter nach 2 Sekunden, dritter nach 4 Sekunden usw.

Zu den Best Practices gehören:

Die Header Retry-After und X-RateLimit-Reset lesen, um genau zu wissen, wann erneut versucht werden kann, statt zu raten. Einen Cache implementieren, um dieselben Anfragen nicht zu wiederholen. Anfragen bündeln (Batching), wenn die API es erlaubt. Anfragen über die Zeit verteilen, statt sie stoßweise zu senden. Einen Circuit Breaker vorsehen, der die API-Aufrufe für eine Weile stoppt, wenn sich 429-Fehler häufen, um die Situation nicht zu verschlimmern.

Rate-Limiting und Datenschutz

IP-basiertes Rate-Limiting bedeutet, dass der Server Anfragen nach IP-Adresse identifiziert und verfolgt. Das ist eine Form der Verarbeitung personenbezogener Daten (die IP-Adresse gilt in vielen Rechtsordnungen als personenbezogenes Datum, insbesondere unter der DSGVO in Europa). Unternehmen, die Rate-Limiting implementieren, sollten diese Verarbeitung theoretisch in ihrer Datenschutzerklärung erwähnen.

Aus Nutzersicht bedeutet IP-basiertes Rate-Limiting auch, dass Ihre Aktivität gezählt wird. Wenn Sie aus Datenschutzgründen ein VPN oder einen Proxy verwenden, kann Rate-Limiting Sie paradoxerweise benachteiligen: Sie teilen sich eine IP mit anderen Nutzern, und das gemeinsame Kontingent erschöpft sich schneller.

Rate-Limiting umgehen

Eine Änderung der IP-Adresse (über ein VPN, einen rotierenden Proxy oder den Flugmodus am Mobiltelefon) ermöglicht es, ein ausschließlich auf IP basierendes Rate-Limiting zu umgehen. Kommerzielle Scraping-Dienste verwenden Pools mit Tausenden von Privat-IP-Adressen, um Anfragen zu verteilen und unter den Schwellenwerten pro IP zu bleiben.

Aber moderne Schutzsysteme beschränken sich nicht auf die IP. Sie kombinieren die Analyse des Browser-Fingerprints, des Surfverhaltens (Klickrhythmus, Mausbewegungen, auf Seiten verbrachte Zeit), CAPTCHAs und die Analyse von Anfragemustern, um Menschen von Bots zu unterscheiden, selbst wenn sich die IP bei jeder Anfrage ändert.

Das Wettrennen zwischen Rate-Limiting-Systemen und Umgehungstechniken ist permanent. Methoden, die heute funktionieren, können morgen erkannt werden. Wenn Sie auf der Serverseite stehen, ist die beste Strategie, mehrere Schutzschichten zu kombinieren, statt sich allein auf die IP zu verlassen.

Beispiele gängiger Limits

Diese Limits variieren enorm je nach Dienst, Preismodell und Kontext. Eine kostenpflichtige API bietet in der Regel deutlich höhere Limits als ein kostenloser Plan. Ein sensibler Endpunkt (Anmeldung, Zahlung, Kontoerstellung) hat deutlich niedrigere Limits als ein Endpunkt zum Lesen von Daten.

IP-Rate-Limiting ist ein wesentlicher Schutz für jeden Server, der dem Internet ausgesetzt ist. Es verhindert Missbrauch, schützt Ressourcen und gewährleistet einen fairen Zugang. Aber die IP-Adresse allein ist mit CGNAT, VPNs und Proxys ein immer weniger verlässlicher Identifikator. Moderne Systeme kombinieren die IP mit anderen Signalen, um legitimen von missbräuchlichem Verkehr zu unterscheiden, und diese Kombination macht den Unterschied zwischen einem wirksamen Schutz und einem einfachen Filter, der leicht zu umgehen ist.