Rate Limiting schützt Webserver nicht nur vor offensichtlichem Missbrauch, sondern auch vor den kleinen Spitzen, die Login-Seiten, APIs oder Download-Endpunkte langsam und teuer machen. Bei Cloudflare geht es dabei um mehr als eine einfache Sperre: Entscheidend sind die richtige Erkennungsregel, die passende Kennzahl pro Client und ein Zeitfenster, das echte Nutzer nicht unnötig ausbremst. In diesem Artikel zeige ich, wie man solche Regeln sinnvoll aufsetzt, welche Werte in der Praxis taugen und wo die Grenzen dieser Schutzschicht liegen.
Die wichtigsten Punkte auf einen Blick
- Cloudflare bewertet nur den Traffic, der zu einer klaren Regel passt, und zählt ihn über definierte Merkmale wie IP, Cookie, Header oder Pfad.
- Ein Limit ist nur dann brauchbar, wenn es zum Anwendungsfall passt, etwa Login, REST-API, Datei-Download oder GraphQL.
- Ich würde Regeln zuerst im Log-Modus testen, dann erst auf Challenge oder Block schalten.
- Die Zähler sind nicht global, sondern an Rechenzentren gebunden. Für exakte Grenzen ist das wichtig.
- Der größte Fehler ist fast immer ein falscher Zählwert, nicht die eigentliche Sperre.
- Für gute Ergebnisse braucht es meist Rate Limiting plus WAF-Regeln, Bot-Schutz und saubere Ausnahmen.
Was die Rate-Limiting-Funktion bei Cloudflare tatsächlich macht
Die Idee ist einfach: Ein Client darf nur so viele Requests in einem definierten Zeitraum schicken, wie du vorher festgelegt hast. Cloudflare vergleicht dafür eingehende Requests mit einer Regel, zählt sie über bestimmte Merkmale hinweg und greift erst ein, wenn der Schwellenwert erreicht ist. Je nach Konfiguration kann die Reaktion ein Log, eine Challenge oder ein Block sein.
Für den Alltag eines Webservers ist das wertvoll, weil du damit sehr gezielt auf Missbrauch reagieren kannst. Ein Login-Endpoint braucht andere Grenzen als ein Produktkatalog oder eine GraphQL-API. Genau deshalb ist Rate Limiting bei Cloudflare keine pauschale Sicherheitskeule, sondern eher ein fein einstellbares Ventil. Und das bringt uns direkt zur Frage, wie Cloudflare überhaupt entscheidet, ob zwei Requests zusammengehören.
Wie Cloudflare Requests zusammenzählt und warum das wichtig ist
Cloudflare zählt nicht einfach blind jede Anfrage hoch. Die Zuordnung läuft über Characteristics, also Merkmale, nach denen der Traffic gruppiert wird. Das kann die IP sein, ein Cookie, ein Header wie ein API-Key, der Pfad, ein Länderfilter oder bei anspruchsvolleren Setups auch ein Fingerprint wie JA3 oder JA4. Bei Enterprise-Tarifen und Advanced Rate Limiting kommen weitere Optionen dazu, zum Beispiel komplexitätsbasierte Regeln für teure Requests.
Wichtig ist dabei ein Punkt, den viele übersehen: Die Zähler sind nicht global über das gesamte Cloudflare-Netz. Sie werden pro Rechenzentrum geführt, mit Ausnahmen innerhalb derselben geografischen Region. Das heißt in der Praxis: Eine Regel kann sehr gut schützen, aber sie ist keine mathematisch perfekte Garantie dafür, dass exakt nur X Requests bis zum Origin gelangen. Für harte Kapazitätsgrenzen solltest du das mit einkalkulieren.
Ich trenne in der Praxis außerdem zwischen dem, was gezählt wird, und dem, woran ich einen Client erkenne. Für ein öffentliches Login ist IP oft ein guter Startpunkt. Für eine API mit Token ist ein Header oder API-Key meist stabiler. Bei gemeinsam genutzten Netzen, mobilen Carriern oder NAT ist eine reine IP-Logik dagegen schnell zu grob. Deshalb lohnt sich der Blick auf die Zählmerkmale besonders, bevor überhaupt die erste Regel live geht.
| Merkmal | Wann ich es nutze | Worauf ich achte |
|---|---|---|
| IP | Öffentliche Endpunkte, einfache Schutzfälle, erste Schutzstufe | Kann bei NAT, Mobilfunk oder Firmennetzen zu Fehlalarmen führen |
| Cookie oder Session | Authentifizierte Nutzer, wiederkehrende Clients, App-Sessions | Funktioniert nur sauber, wenn der Client wirklich ein stabiles Cookie hat |
| Header wie API-Key | REST-APIs, Partnerzugänge, Maschinen-zu-Maschinen-Traffic | Headernamen müssen konsistent sein, sonst entstehen Lücken |
| Pfad | Dateidownloads, einzelne Endpunkte, spezielle Aktionen | Nur sinnvoll, wenn der Pfad das eigentliche Ziel der Belastung ist |
| JA3 oder JA4 | Botnahe Muster, erweiterte Schutzszenarien | Stärker, aber nur mit passender Produktstufe und sauberer Analyse |
Mit diesem Modell im Kopf wird die eigentliche Einrichtung deutlich einfacher, denn die nächste Frage lautet: Welche Regel greift, und wie wird sie in Cloudflare sinnvoll angelegt?
So richte ich eine Regel im Dashboard sauber ein
Im Dashboard läuft der Prozess recht geradlinig ab: Du gehst zu den Security Rules, legst eine Rate-Limiting-Regel an, definierst die Filterexpression, wählst die Characteristics, setzt das Zeitfenster und bestimmst die Aktion. Technisch ist das schnell angeklickt. Die eigentliche Arbeit steckt in der Auswahl der richtigen Filter und in einer vernünftigen Teststrategie.
Mein Standardvorgehen sieht so aus:
- Ich grenze den betroffenen Endpunkt so eng wie möglich ein, zum Beispiel nur
/loginoder nur eine bestimmte API-Route. - Ich wähle die Kennzahl für den Client, meistens IP, API-Key, Cookie oder Pfad.
- Ich starte mit Log, nicht mit Block.
- Ich prüfe, ob die Regel zu viele legitime Nutzer trifft.
- Erst danach schalte ich auf Challenge oder Block um.
Bei den Aktionen arbeite ich sehr bewusst gestaffelt. Log ist der sichere Start, weil ich damit sehe, wie die Regel wirklich wirkt. Managed Challenge ist oft ein guter Mittelweg, wenn ich legitime Nutzer nicht hart aussperren will. Block setze ich erst dann ein, wenn ich das Muster verstanden habe. Für Enterprise-Setups gibt es zusätzlich die Option, Requests über dem Limit zu drosseln statt nur hart zu blockieren, was bei APIs manchmal die elegantere Lösung ist.
| Aktion | Wann ich sie nehme | Stärke | Risiko |
|---|---|---|---|
| Log | Zum Testen und Tuning | Keine direkte Sperre, aber volle Sichtbarkeit | Schützt noch nicht aktiv |
| Managed Challenge | Wenn ich zwischen Mensch und Bot unterscheiden will | Sehr brauchbar gegen automatisierte Versuche | Kann einzelne Nutzer irritieren |
| Block | Bei klaren Missbrauchsmustern | Hart und eindeutig | Fehlkonfiguration trifft sofort echte Nutzer |
| Throttle | Wenn ich Überlast bremsen, aber nicht alles stoppen will | Guter Kompromiss für APIs | Verfügbar nicht in jedem Tarif |
Gerade im Dashboard ist außerdem die Option wichtig, Rate Limiting auf cached assets anzuwenden oder eben nicht. Wenn du nur Requests zählen willst, die tatsächlich zum Origin gehen, solltest du das bewusst prüfen. Sonst misst du am Ende an einer Stelle, die mit dem eigentlichen Serveraufwand nur indirekt zu tun hat. Die technische Einrichtung ist damit erst der halbe Job, denn die Qualität der Schwelle entscheidet über Erfolg oder Frust.
Welche Schwellen und Zeitfenster in der Praxis sinnvoll sind
Die wichtigste Regel aus der Praxis ist banal, aber entscheidend: Ich behandle Startwerte nie als Endwerte. Ein gutes Limit ergibt sich aus echtem Traffic, nicht aus einem Bauchgefühl. Für Login- und Verifikationsendpunkte will ich eher kurze Fenster und niedrige Schwellen, bei APIs brauche ich meist eine feinere Zuordnung pro Schlüssel oder Session, und bei Downloads oder GraphQL ist die Kostenlast pro Request wichtiger als die reine Menge.
Als grobe Orientierung nutze ich gern diese Startpunkte:
| Szenario | Solider Startwert | Warum das sinnvoll ist |
|---|---|---|
| Login-Formular | 4 bis 10 Versuche pro Minute pro IP | Schützt gegen Brute Force, lässt menschliche Fehlversuche aber noch zu |
| OTP- oder Verifikationsseite | 5 fehlgeschlagene Versuche pro Minute | Codes werden schnell erraten, deshalb muss das Fenster eng sein |
| REST-API mit Authentifizierung | Pro API-Key und Endpunkt anhand von Analysen festlegen | Fairer als eine reine IP-Grenze, vor allem bei NAT oder gemeinsam genutzten Netzen |
| Dateidownloads | 10 Downloads pro 10 Minuten pro Pfad und Client | Verhindert Bandbreitenmissbrauch, ohne den Zugriff unbrauchbar zu machen |
| GraphQL | Operationen oder Complexity-Budget pro Stunde | Eine einzelne Anfrage kann viel teurer sein als zehn einfache Reads |
Besonders hilfreich ist die Analyse über echte Nutzungsdaten. Cloudflare bietet dafür eine Request-Rate-Ansicht, mit der du die Verteilung des Traffics prüfen kannst. Ich würde eine Regel immer zuerst im Log-Modus ausrollen und dann beobachten, wie viele Nutzer sie wirklich treffen würde. So erkenne ich früh, ob ich einen Ausreißer blockiere oder versehentlich den Durchschnitt.
Für Login-Strecken funktioniert oft ein gestaffeltes Modell am besten: erst eine milde Challenge, dann eine deutlich längere Sperre. Bei API-Last oder Ressourcenschutz ist eher eine saubere, konstante Drosselung sinnvoll. Damit ist die Frage nach den Zahlen beantwortet, aber noch nicht die nach den konkreten Einsatzfällen auf einem Webserver.
Wofür sich Rate Limiting auf Webservern besonders gut eignet
In der Praxis sehe ich immer wieder dieselben drei Hochrisikozonen: Authentifizierung, teure API-Aufrufe und Ressourcen mit hohem Abrufvolumen. Genau dort liefert die Technik den größten Nutzen. Sie ersetzt keine WAF und keinen Bot-Schutz, aber sie verhindert sehr oft, dass ein einzelner Client das System aus dem Takt bringt.
Login und Kontoschutz
Für Login-Seiten ist die Schutzwirkung am offensichtlichsten. Credential Stuffing lebt davon, dass Angreifer viele Anmeldeversuche automatisiert absetzen. Wenn ich die Regel auf Fehlversuche, also zum Beispiel 401 oder 403, aufbaue, treffe ich genau den Teil des Traffics, der problematisch ist. Das ist sauberer als eine reine Gesamtzählung, weil normale Nutzer mit einem falschen Passwort nicht sofort abgestraft werden müssen.
REST-APIs und Download-Endpunkte
Bei REST-APIs zählt für mich vor allem Fairness pro Kunde oder Schlüssel. Ein API-Key ist hier meist die bessere Identität als eine IP. Für Dateidownloads ist der Pfad oft das richtige Merkmal, weil ich nicht für jede einzelne Datei eine neue Regel schreiben will. Gerade bei größeren Beständen ist das der Unterschied zwischen sauberem Betrieb und Regel-Chaos.
Lesen Sie auch: Nginx Proxy Manager 502 - Bad Gateway schnell beheben
GraphQL und teure Operationen
GraphQL ist ein Sonderfall, weil viele Operationen über einen einzigen Endpoint laufen. Eine Anfrage kann extrem leicht oder sehr teuer sein. Deshalb halte ich reine Request-Zahlen dort für zu grob. Besser ist ein Modell, das die Anzahl der Operationen oder sogar deren Komplexität bewertet. Cloudflare unterstützt dafür entsprechende Ansätze, solange die Origin-Seite die nötigen Scores oder Header liefert. Das ist technisch etwas aufwendiger, aber in modernen APIs oft die sauberste Variante.
Der eigentliche Mehrwert liegt also nicht in der Sperre selbst, sondern darin, die Schutzregel an das Verhalten des Endpunkts anzupassen. Und genau da passieren die meisten Fehler, wenn man zu schnell zu allgemein denkt.
Welche Fehler ich bei Cloudflare immer wieder sehe
Die häufigste Schwachstelle ist nicht der Dienst, sondern die Modellierung. Viele Regeln sind zu breit, zu früh scharf geschaltet oder auf die falsche Identität gebaut. Das führt zu unnötigen Sperren, unsauberen Metriken und am Ende zu Vertrauensverlust im Betrieb.
- Nur nach IP zu zählen, obwohl der Traffic über NAT oder Mobilfunk kommt.
- Eine Regel auf den falschen Pfad zu legen, etwa
/validate/otpstatt/api/otp/validate. - Ohne Log-Phase direkt auf Block zu gehen.
- Cached Assets mitzuzählen, obwohl nur Origin-Last relevant ist.
- Zu erwarten, dass ein Limit millimetergenau jede einzelne Anfrage abfängt.
- Verified Bots oder wichtige Integrationen mitzuerfassen, ohne Ausnahmen zu definieren.
Auch die Reihenfolge der Regeln spielt eine Rolle. Wenn eine härtere Regel zuerst greift, kann sie andere Prüfungen praktisch aushebeln. Dazu kommt, dass die Zähler in der Praxis mit leichter Verzögerung aktualisiert werden können. Wer auf exakte, mathematisch perfekte Durchsetzung setzt, wird enttäuscht. Wer dagegen mit vernünftigen Reserven plant, bekommt ein robustes Ergebnis.
Ein weiterer Punkt, den ich ernst nehme, ist die Suchmaschinen- und Bot-Seite. Wenn du versehentlich legitime, verifizierte Bots zu hart einschränkst, kann das SEO oder Integrationen beeinträchtigen. Deshalb ist es klug, zuerst das Muster zu verstehen und erst dann strikt zu werden. Von hier ist der nächste Schritt naheliegend: die Regel nicht isoliert zu betrachten, sondern in eine Schutzkette einzubauen.
Wie ich Rate Limiting mit WAF, Bot-Schutz und Ausnahmen kombiniere
Allein ist die Funktion nützlich, zusammen mit anderen Schutzschichten wird sie stark. Ich verwende sie gern als zweite oder dritte Linie, nicht als einzige. Vorne stehen klare WAF-Regeln für offensichtliche Muster, danach Rate Limiting für wiederholte Missbrauchsversuche und je nach Setup Bot-Management oder Challenges für verdächtige, aber nicht eindeutig bösartige Clients.
In der Praxis sieht die Reihenfolge oft so aus:
- Bekannte schlechte Muster direkt per WAF-Regel aussortieren.
- Sensible Endpunkte mit Rate Limiting absichern.
- Bei auffälligem Verhalten eine Challenge statt eines harten Blocks einsetzen.
- Für APIs, die mit Token, JWT oder speziellen Headern arbeiten, die Kennzahl genau auf diesen Identifikator ausrichten.
- Interne Systeme, Monitoring, CI/CD oder Admin-Zugriffe bewusst ausnehmen.
Das ist auch der Punkt, an dem ich Ausnahmen nie als Nachgedanken behandle. Eine saubere Allowlist für interne IPs, bestimmte ASNs, Admin-Tools oder vertrauenswürdige Integrationen spart später sehr viel Zeit. Wenn du die Regel nur auf Verdacht scharf stellst, wirst du irgendwann deine eigenen Automatismen blockieren. Besser ist ein kontrolliertes Setup mit klarer Zuständigkeit pro Schutzschicht. Damit bleibt nur noch die Frage, worauf ich vor dem Livegang selbst noch einmal prüfend schaue.
Vor dem Livegang prüfe ich immer diese Punkte
- Passt die Expression wirklich exakt zum betroffenen Endpoint?
- Ist die gewählte Kennzahl stabil genug für echte Nutzer, Bots und API-Clients?
- Habe ich die Regel zuerst im Log-Modus getestet?
- Ist klar, ob cached Assets mitgezählt werden sollen oder nicht?
- Gibt es saubere Ausnahmen für interne Nutzer, Monitoring und Automatisierung?
- Weiß ich, welche Reaktion im Ernstfall ausgelöst wird, also Log, Challenge, Block oder Drosselung?
Wenn diese Punkte stimmen, wird aus einer bloßen Schutzfunktion ein belastbares Betriebsmittel. Genau dann verhindert Cloudflare nicht nur Missbrauch, sondern hält auch Lastspitzen, Fehlversuche und automatisierte Zugriffe so in Schach, dass dein Webserver stabil bleibt und echte Nutzer kaum etwas davon merken.
