HTTP-Statuscodes erklärt: 2xx, 3xx, 4xx und 5xx

Was sind HTTP-Statuscodes?

Jedes Mal, wenn ein Browser oder ein Monitoring-Tool eine Anfrage an einen Webserver schickt, antwortet dieser mit einem dreistelligen Zahlencode. Dieser Code gibt Auskunft darüber, wie die Anfrage verarbeitet wurde. Entwickler und Systemadministratoren nutzen diese Codes täglich zur Fehleranalyse, und auch wer Websites betreibt, sollte die wichtigsten Codes kennen.

Die Codes sind in fünf Klassen eingeteilt. Die erste Ziffer bestimmt die Klasse:

• 1xx: Informationsantworten (selten im Alltag relevant)
• 2xx: Erfolgreiche Anfragen
• 3xx: Weiterleitungen
• 4xx: Fehler auf Client-Seite
• 5xx: Fehler auf Server-Seite

2xx: Erfolgreiche Antworten

Diese Gruppe signalisiert, dass die Anfrage angekommen ist und erfolgreich bearbeitet wurde.

200 OK ist der häufigste Code überhaupt. Die Seite wurde gefunden, der Server hat die Anfrage verarbeitet und liefert den Inhalt zurück. Jede funktionierende Website sollte für ihre Hauptseiten diesen Code liefern.

201 Created tritt auf, wenn eine Ressource durch die Anfrage neu erstellt wurde. Das begegnet einem vor allem bei REST-APIs, wenn etwa ein neuer Datensatz angelegt wird.

204 No Content bedeutet, die Anfrage war erfolgreich, aber der Server sendet keinen Inhalt zurück. Das ist typisch für DELETE-Anfragen oder bestimmte API-Endpunkte.

206 Partial Content zeigt an, dass der Server nur einen Teil der angeforderten Ressource sendet. Das kommt beim Streaming von Videos oder beim Fortsetzen von Downloads vor.

3xx: Weiterleitungen

Weiterleitungen teilen dem anfragenden Browser mit, dass er die Ressource unter einer anderen Adresse finden kann.

301 Moved Permanently ist eine dauerhafte Weiterleitung. Suchmaschinen übernehmen den Link-Wert der alten URL auf die neue. Dieser Code wird verwendet, wenn eine Domain umzieht oder URLs dauerhaft umstrukturiert werden.

302 Found ist eine temporäre Weiterleitung. Der Browser folgt der Umleitung, merkt sich aber die ursprüngliche URL als gültig.

304 Not Modified ist kein Fehler, sondern ein Caching-Signal. Der Server sagt dem Browser: Deine gespeicherte Version ist noch aktuell, du musst die Ressource nicht erneut laden.

307 Temporary Redirect verhält sich ähnlich wie 302, schreibt dem Browser aber vor, die ursprüngliche HTTP-Methode (GET, POST) beizubehalten.

308 Permanent Redirect ist die strenge Variante von 301 mit Methodenerhalt.

4xx: Client-Fehler

Bei diesen Codes liegt das Problem auf der Seite des Anfragenden, also beim Browser oder dem Client. Das kann eine falsche URL sein, fehlende Berechtigung oder eine ungültige Anfrage.

400 Bad Request bedeutet, die Anfrage war fehlerhaft formuliert. Der Server kann sie nicht verarbeiten, weil Syntax oder Format nicht stimmen.

401 Unauthorized zeigt an, dass Authentifizierung erforderlich ist. Der Nutzer muss sich einloggen, bevor er auf die Ressource zugreifen darf.

403 Forbidden unterscheidet sich von 401 dadurch, dass die Authentifizierung allein nicht hilft. Der Server versteht die Anfrage, verweigert aber den Zugriff aus anderen Gründen, zum Beispiel weil die IP-Adresse gesperrt ist oder die Datei nicht öffentlich zugänglich ist.

404 Not Found ist der bekannteste Fehlercode. Die angeforderte Seite existiert nicht auf dem Server. Das passiert bei toten Links, gelöschten Seiten oder Tippfehlern in der URL.

405 Method Not Allowed tritt auf, wenn die verwendete HTTP-Methode für diese URL nicht erlaubt ist, zum Beispiel wenn jemand einen GET-Request an einen Endpunkt schickt, der nur POST akzeptiert.

429 Too Many Requests ist ein Rate-Limiting-Signal. Der Client hat zu viele Anfragen in kurzer Zeit gestellt. Viele APIs nutzen diesen Code, um Missbrauch zu verhindern.

5xx: Server-Fehler

Bei den 5xx-Codes liegt das Problem auf der Serverseite. Der Server hat die Anfrage empfangen, konnte sie aber nicht erfolgreich verarbeiten.

500 Internal Server Error ist der generische Serverfehlermeldung. Irgendetwas ist intern schiefgelaufen, ohne dass der Server einen spezifischeren Code zurückliefert. Ursachen können Programmierfehler, abgestürzte Dienste oder Datenbankprobleme sein.

502 Bad Gateway erscheint, wenn ein Reverse Proxy oder Load Balancer keine gültige Antwort vom Ursprungsserver bekommt. Das passiert häufig bei Nginx- oder Cloudflare-Setups, wenn der dahinterliegende Anwendungsserver nicht antwortet.

503 Service Unavailable zeigt an, dass der Server vorübergehend nicht verfügbar ist. Häufige Ursachen sind Überlastung oder geplante Wartungsarbeiten. Server können bei diesem Code einen Retry-After-Header mitsenden, um anzuzeigen, wann sie wieder verfügbar sein werden.

504 Gateway Timeout ist ähnlich wie 502, aber mit einem Zeitüberschreitungsproblem: Der Proxy hat zu lange auf eine Antwort des Ursprungsservers gewartet.

507 Insufficient Storage ist selten, tritt aber auf, wenn dem Server der Speicherplatz ausgeht und er deswegen keine Daten mehr speichern kann.

Statuscodes richtig interpretieren

Bei der Überwachung von Websites zeigt das Tool auf website-status-checker.de den jeweiligen Statuscode an. Das hilft dabei, die Art eines Problems einzugrenzen:

Ein 5xx-Code ist immer ein Alarmsignal, das sofortiges Handeln erfordert. Ein 4xx-Code deutet auf ein Konfigurationsproblem hin, das man gezielt angehen kann. Ein 3xx-Code ist in der Regel kein Problem, sofern die Weiterleitungskette nicht zu lang ist.

Wichtig ist außerdem, auf Weiterleitungsschleifen zu achten. Wenn zwei URLs sich gegenseitig weiterleiten, endet das im Browser mit einer Fehlermeldung. Monitoring-Tools erkennen solche Schleifen anhand einer zu hohen Anzahl von Weiterleitungen.

Caching und Statuscodes

Ein häufiges Missverständnis ist, dass ein 200-Code immer bedeutet, der Server habe frischen Inhalt geliefert. Tatsächlich kann der Browser oder ein CDN eine gecachte Antwort ausliefern, ohne den Ursprungsserver zu kontaktieren. Das erklärt, warum manche Änderungen erst nach Minuten oder Stunden sichtbar werden, obwohl der Server bereits den aktualisierten Inhalt vorhält.

Für das Monitoring ist deshalb zu beachten, dass manche Prüftools Caching umgehen, indem sie Anfragen mit einem Cache-Control: no-cache-Header senden. So stellt man sicher, dass die Prüfung den tatsächlichen Serverzustand widerspiegelt und nicht einen veralteten Cache-Eintrag.