HTTP-Statuscodes

HTTP-Statuscodes sind dreistellige Zahlen, die ein Server in der Antwort zurückschickt, um das Ergebnis einer Anfrage zu beschreiben. 200 bedeutet, die Anfrage war erfolgreich, 404 bedeutet, die Seite wurde nicht gefunden, und 500 bedeutet, der Server ist auf einen Fehler gestoßen. Die erste Ziffer ordnet den Code in eine von fünf Klassen ein — 2xx steht immer für Erfolg, 5xx immer für einen Server-Fehler — sodass allein die Klasse sofort zeigt, wo mit der Fehlersuche begonnen werden sollte: auf der Client-Seite oder auf der Server-Seite.

Die erste Ziffer definiert die Klasse: 1xx Informational (die Anfrage wurde empfangen und läuft weiter, z. B. 100 Continue), 2xx Success (erfolgreich, z. B. 200 OK), 3xx Redirection (Weiterleitung erforderlich, z. B. 301 Moved Permanently), 4xx Client error (fehlerhafte Anfrage, z. B. 404 Not Found) und 5xx Server error (Server-Fehler, z. B. 500 Internal Server Error). Im obigen Werkzeug nach beliebiger Klasse filtern, um nur diese Gruppe mit Erläuterungen zu jedem Code zu sehen.

Die Codes, denen man täglich begegnet, sind 200 OK, 201 Created, 204 No Content, 301 und 302 Weiterleitungen, 304 Not Modified, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests, 500 Internal Server Error, 502 Bad Gateway und 503 Service Unavailable. Mit „Nur häufige" im obigen Werkzeug lässt sich die vollständige Liste auf genau diese Kurzliste reduzieren — mit Ursachen und Lösungen für jeden Eintrag.

200 OK ist die Standard-Erfolgsantwort — bei einem GET wird die Ressource im Antwortkörper zurückgegeben, bei einem POST das Ergebnis der Aktion. 201 Created bedeutet, ein POST oder PUT war erfolgreich und hat eine neue Ressource angelegt; der Server gibt die Adresse der neuen Ressource normalerweise in einem Location-Header zurück, z. B. Location: /users/42. Beim Aufbau einer API, die eine Ressource anlegt, sollte 201 mit einem Location-Header zurückgegeben werden — nicht 200 — damit Clients wissen, wo sich das neue Objekt befindet.

404 bedeutet, der Server konnte unter dieser URL nichts finden — sie existiert nicht, wurde verschoben, oder der Link ist defekt. Beheben lässt sich das durch Prüfen der URL auf Tippfehler und falsche Groß-/Kleinschreibung, Einrichten einer 301-Weiterleitung von der alten zur neuen Adresse, Überprüfen der Routing- oder Rewrite-Regeln des Servers sowie Bereitstellen einer hilfreichen eigenen 404-Seite. Anders als 410 Gone verspricht 404 nicht, dass die Ressource dauerhaft verschwunden ist — Suchmaschinen crawlen sie daher weiter. Die MDN Web Docs decken die Spezifikation gut ab, aber dieses Werkzeug zeigt häufige Ursachen und Lösungen direkt neben dem jeweiligen Code.

301 Moved Permanently teilt mit, dass die Ressource dauerhaft eine neue Adresse hat — Suchmaschinen übertragen Ranking-Signale auf die neue URL und aktualisieren ihren Index. Zu verwenden, wenn eine URL dauerhaft geändert wird. 302 Found ist temporär: Die ursprüngliche URL bleibt kanonisch und behält ihr Ranking — zu verwenden für kurzfristige Verschiebungen wie A/B-Tests oder eine Wartungsseite. Für Nicht-GET-Anfragen sollten 308 (dauerhaft) oder 307 (temporär) verwendet werden, da diese die HTTP-Methode beibehalten statt Browser zu erlauben, ein POST zu einem GET herabzustufen.

403 Forbidden bedeutet, der Server hat die Anfrage verstanden, verweigert aber die Ausführung — und anders als bei 401 hilft das Senden von Anmeldedaten nicht weiter. Typische Ursachen sind fehlende Berechtigungen oder Zugriffsrechte für den Account, falsche Dateiberechtigungen auf dem Server (z. B. eine Datei mit 600 statt 644), eine IP-Sperre oder WAF-Regel oder ein deaktiviertes Verzeichnislisting ohne vorhandene Indexdatei. Rollen des Accounts, Dateiberechtigungen und etwaige Allowlists überprüfen. Manche Server geben absichtlich 403 statt 404 zurück, um nicht preiszugeben, dass eine Ressource überhaupt existiert.

Alle sind 5xx-Server-Fehler, bedeuten aber Verschiedenes. 500 Internal Server Error ist ein generisches "etwas ist schiefgelaufen" — meist eine unbehandelte Ausnahme oder ein Bug in der Anwendung. 502 Bad Gateway bedeutet, ein Proxy hat eine ungültige Antwort vom vorgelagerten App-Server erhalten (dieser ist häufig abgestürzt). 503 Service Unavailable bedeutet, der Server ist vorübergehend nicht verfügbar oder überlastet — er sollte einen Retry-After-Header zurückgeben. 504 Gateway Timeout bedeutet, der vorgelagerte Server war zwar erreichbar, hat aber nicht rechtzeitig geantwortet. Mit Server-Logs lassen sich diese Fälle in der Praxis voneinander unterscheiden.

429 bedeutet, ein Ratenlimit wurde überschritten — zu viele Anfragen in einem bestimmten Zeitfenster. Der Server sollte einen Retry-After-Header zurückgeben, der angibt, wie lange gewartet werden soll. Beheben lässt sich das durch Einhalten dieses Headers, Hinzufügen von exponentiellem Backoff zwischen Wiederholungsversuchen, Caching von Antworten zur Reduzierung des Anfragevolumens oder Anfragen eines höheren Kontingents. Der Code tritt häufig bei öffentlichen APIs und Login-Endpunkten auf, die vor Missbrauch schützen. GitHub, Stripe und Twitter/X verwenden 429 für API-Ratenbegrenzung.

4xx-Fehler liegen beim Client — die Anfrage selbst ist falsch, sodass ein unverändertes Wiederholen nicht hilft (400 Bad Request, 401 Unauthorized, 404 Not Found). 5xx-Fehler liegen beim Server — die Anfrage kann völlig korrekt sein, aber der Server konnte sie nicht erfüllen (500, 502, 503); dieselbe Anfrage kann erfolgreich sein, sobald der Server sich erholt hat. Bei 4xx muss die Anfrage korrigiert werden, bei 5xx der Server. Diese Unterscheidung ist wichtig für Wiederholungslogik: Nur bei 5xx mit exponentiellem Backoff wiederholen — bei 4xx verbrennt das nur Anfragekontingent ohne Nutzen.

Die entscheidenden Codes sind 200 OK (jede indexierbare Seite sollte diesen zurückgeben), 301 Moved Permanently (überträgt Ranking-Signale bei Migrationen auf eine neue URL), 302 Found (temporär — die ursprüngliche URL behält ihre Autorität), 404 Not Found und 410 Gone (signalisieren Crawlern, dass eine Seite fehlt; 410 wird schneller aus dem Index entfernt, weil es das dauerhafte Verschwinden signalisiert) sowie 503 Service Unavailable (der SEO-sichere Code für geplante Wartungszeiten — teilt Google mit, dass später erneut gecrawlt werden soll, statt die Seite zu de-indexieren).

401 Unauthorized bedeutet eigentlich "nicht authentifiziert" — die Identität wurde nicht nachgewiesen, sodass das Senden gültiger Anmeldedaten (Token, API-Schlüssel oder Anmeldesitzung) das Problem beheben kann; der Server sollte mit einem WWW-Authenticate-Header antworten. 403 Forbidden bedeutet, die Authentifizierung ist vorhanden, aber der Zugriff auf diese Ressource ist schlicht nicht erlaubt — bessere Anmeldedaten helfen nicht, andere Berechtigungen werden benötigt. Faustregel: 401 = Wer bist du?, 403 = Das darfst du nicht.

Alle vier sind Weiterleitungen, aber 307 und 308 garantieren, dass die ursprüngliche HTTP-Methode und der Anfragekörper erhalten bleiben, während 301 und 302 Clients historisch erlauben, ein POST bei der weitergeleiteten Anfrage in ein GET umzuwandeln. 301 (dauerhaft) und 302 (temporär) eignen sich daher gut für einfache Seitenumleiten, aber für Endpunkte, die POST- oder PUT-Daten empfangen, sollte 308 für dauerhafte und 307 für temporäre Verschiebungen verwendet werden, um die Methode beizubehalten und Datenverlust zu vermeiden.

Codes im Bereich 520–530 sind nicht-standardisierte Codes, die Cloudflare zurückgibt, wenn zwischen Cloudflare und dem Ursprungsserver etwas schiefläuft — sie gehören nicht zum offiziellen HTTP-Standard, begegnen einem aber ständig hinter Cloudflare. 520 bedeutet, der Ursprungsserver hat eine leere oder unerwartete Antwort geschickt, 521 bedeutet, der Ursprungsserver hat die Verbindung verweigert (er ist offline oder blockiert Cloudflare per Firewall), 522 bedeutet, die TCP-Verbindung hat das Zeitlimit überschritten, 523 bedeutet, der Ursprungsserver ist nicht erreichbar, 524 bedeutet, der Server hat verbunden, aber nicht innerhalb von 100 Sekunden geantwortet, 525 und 526 sind SSL-Handshake- und Zertifikatsfehler, und 530 ist meist ein DNS-Fehler am Ursprungsserver, begleitet von einem 1xxx-Code. Jede dieser Nummern lässt sich oben suchen, um Ursachen und Lösungen zu sehen.

MDN Web Docs ist die maßgebliche Spezifikationsreferenz, bietet aber keine Live-Suchleiste, keine Klassenfilterung und keine kompakte Spickzettel-Ansicht — man navigiert eine Seite pro Code. httpstatuses.com zeigt Codes in einem Raster, erklärt aber keine Ursachen und praktischen Lösungen. restapitutorial.com behandelt REST-Konventionen ohne interaktive Suche. HTTP.cat ist ein unterhaltsamer Meme-Auftritt (jeder Code wird einem Katzenfoto zugeordnet), aber für echtes Debugging ungeeignet. Dieses Werkzeug kombiniert eine durchsuchbare Referenz, Klassenfilter, Spickzettel-Modus, verständliche Ursachen und Lösungen sowie die Cloudflare-5xx-Codes, die die meisten Referenzen auslassen — alles auf einer Seite, die offline läuft, ohne Werbung und ohne Anmeldung.

Vollständig. Die gesamte Liste wird als statische Daten direkt mit der Seite ausgeliefert, sodass jede Suche, jeder Filter und jede Abfrage lokal im Browser läuft — nichts wird hochgeladen, protokolliert oder an einen Server gesendet. Das bedeutet auch, dass die Seite sofort lädt und offline funktioniert, sobald sie einmal geöffnet wurde. Kein Account, kein Login, keine Ratenbegrenzung und keine Bezahlschranke. Einfach eine schnelle, private Referenz, die auf dem Smartphone genauso gut funktioniert wie am Desktop.