Klassisches Rate Limiting zählt, wie viele Anfragen jede IP sendet, und blockiert die, die die Grenze überschreitet. Das funktioniert hervorragend gegen einen einzelnen, hartnäckigen Angreifer — und ist völlig nutzlos gegen einen echten Denial-of-Service-Angriff, weil ein Botnetz gleichzeitig Hunderte oder Tausende verschiedener IPs nutzt: Jede schickt nur eine Handvoll Anfragen und startet ihren eigenen, frischen Zähler. Genau für dieses Szenario wurde DDoS Resilience gebaut.
Warum das Zählen pro IP nicht reicht
Liegt deine Rate-Limiting-Grenze bei “nach 100 Anfragen pro Minute blockieren”, löst ein Botnetz aus 1.000 IPs mit je 50 Anfragen die Grenze bei keiner einzigen IP aus — und trotzdem sind es 50.000 echte Anfragen pro Minute, die auf deinem Server landen. Das Problem ist keine falsch eingestellte Zahl — es ist die falsche Maßeinheit.
So funktioniert DDoS Resilience
Es zählt den globalen Traffic der Seite, nicht IP für IP
Statt eines Zählers pro Adresse addiert DDoS Resilience jede Anfrage der gesamten Website, aus allen IPs zusammen, in 10-Sekunden-Fenstern. Überschreitet diese Summe den von dir eingestellten Schwellenwert (Anfragen pro Minute, für die ganze Seite), springt der “Flood-Modus” an — und bleibt noch einige Minuten aktiv, selbst wenn der Traffic kurz nachlässt, damit er nicht ständig an- und ausschaltet, während ein Angriff knapp um die Grenze schwankt.
Eine Prüfung, die ein Bot nie besteht — und ein Mensch nie bemerkt
Bei aktivem Flood-Modus bekommt jeder neue Besucher statt deines vollständigen WordPress eine schlanke Seite: eine kurze Meldung “Dein Browser wird geprüft…” mit einem winzigen Skript, das zwei Zufallszahlen addiert und die Antwort selbstständig absendet, in unter einer Sekunde. Ein echter Browser löst das, ohne dass der Besucher irgendetwas tut oder es überhaupt bemerkt. Ein typischer Flood-Bot — ein Skript, das nur rohe HTTP-Anfragen sendet, ohne JavaScript-Engine — führt dieses Skript nie aus, schickt nie eine Antwort und bleibt für immer ausgesperrt.
Signiert und zeitlich begrenzt — nicht fälsch- oder wiederverwendbar
Die Antwort wird mit HMAC signiert, unter Verwendung von WordPress’ eigenem internen Geheimnis, und läuft nach 60 Sekunden ab. Das schließt aus, eine gültige Antwort im Voraus zu berechnen oder eine alte wiederzuverwenden. Nach erfolgreicher Lösung erhält der Besucher ein Cookie — ebenfalls signiert —, das ihn für die von dir eingestellte Zeit (standardmäßig 15 Minuten) ohne weitere Prüfung durchlässt.
Wer die Prüfung nie zu sehen bekommt
Bevor sie überhaupt jemandem gezeigt wird, sind ausgenommen: bereits angemeldete Administratoren, IPs auf deiner Whitelist, echt verifizierte Crawler (Google, GPTBot… per Reverse-DNS bestätigt, nicht nur behauptet über den User-Agent) sowie WordPress-interne Routen — Login, Cron, admin-ajax, REST-API —, deren versehentliche Blockierung die Verwaltung deiner eigenen Seite lahmlegen würde. Geprüft werden nur normale Seitenaufrufe (GET); Formulare und API-Aufrufe laufen ungehindert durch, damit Zahlungen und Integrationen nicht mitten in einem Angriff kaputtgehen.
Was auf deinem Server während des Angriffs passiert
Der wichtige Teil: Diese Prüfung wird ausgeliefert, bevor WordPress überhaupt lädt. Ein im Prüfungs-Loop gefangener Bot lässt deine Datenbank oder PHP nie wirklich arbeiten — er bekommt eine statische Seite von wenigen Kilobyte und einen 503-Status, keine vollständige WordPress-Ausführung. Genau das hält deine Seite für echte Besucher normal erreichbar, selbst bei riesigem Gesamt-Anfragevolumen.
Häufige Fragen
Blockiert das Google oder meine echten Besucher?
Nein. Echt verifizierte Crawler sind ausgenommen, und jeder echte Besucher mit aktiviertem JavaScript (die überwältigende Mehrheit) löst die Prüfung von selbst, in unter einer Sekunde, ohne ein CAPTCHA zu sehen oder irgendetwas tun zu müssen.
Muss ich etwas tun, wenn ein Angriff beginnt?
Nein — es schaltet sich selbstständig ein und aus, basierend auf dem globalen Echtzeit-Traffic der Seite. Den Schwellenwert, wie lange ein Besucher als geprüft gilt, und die Abklingzeit nach einem Peak kannst du im Dashboard anpassen.
Ersetzt das ein CDN wie Cloudflare?
Nicht vollständig, und das ist wichtig zu wissen: DDoS Resilience schützt die Anwendungsebene (Layer 7) — den HTTP-Traffic, der bei WordPress ankommt. Es ersetzt kein Edge-Netzwerk, das Angriffe auf Netzwerkebene (Layer 3/4) abfangen soll, bevor sie überhaupt deinen Server erreichen. Es ist eine zusätzliche Schicht, nicht die einzige, die du haben solltest, wenn das DDoS-Risiko für dein Geschäft hoch ist.