Fallstudie: Cloudflare 403 vs. echter Ausfall

Ein Support-Team meldete „Website down“, nachdem Monitoring-Checks 403-Antworten erhielten. Endnutzer konnten die Startseite im Browser weiterhin laden. Dieser Fall erklärt, wie man diesen Widerspruch auflöst.

Beobachtete Symptome

• Automatisierte Checks lieferten HTTP 403.
• Browser-Nutzer sahen gelegentlich Challenge-Seiten, danach Erfolg.
• Keine Hinweise auf Origin-Server-Abstürze oder 5xx-Fehler.

Verwendete Diagnosereihenfolge

1. URL im Website-Checker ausführen und Statustext sowie Hinweise erfassen.
2. Prüfen, ob die Antwort Bot-Schutz-Muster enthält (Cloudflare-Challenge-Hinweise).
3. Im Browser testen und mit serverseitigem Check-Verhalten vergleichen.
4. WAF-/Rate-Limit-Schwellenwerte in Edge-Einstellungen prüfen.

Ursache

Die Website war online, aber WAF-Einstellungen stuften Nicht-Browser-Traffic als verdächtig ein. Synthetische Checks wurden an der Edge blockiert, bevor vollständiger Seiteninhalt erreicht wurde.

Behebung und Validierung

• Bot-/WAF-Regeln für erwartetes Monitoring-Verhalten angepasst.
• Aggressive Rate-Limit-Einstellungen für Diagnose-Endpunkte reduziert.
• Erneut getestet: Checker wechselte von blockiert/eingeschränkt zu stabilen Online-Antworten.

Erkenntnisse

• 403 bedeutet nicht immer Ausfall.
• Verschiedene Request-Typen können unterschiedliche Ergebnisse liefern.
• Checker-Status mit Edge-Security-Logs abgleichen, bevor ein Ausfall deklariert wird.

Weiterführende Lektüre: Leitfaden 500/502/503 und Methodik.