Der ultimative Leitfaden zu HTTP-Statuscodes
HTTP-Statuscodes geben das Ergebnis der Anfrageverarbeitung eines Webservers an. Sie sind in fünf Klassen gruppiert, die jeweils eine andere Kategorie von Antworten repräsentieren. Das Verständnis dieser Codes ist für Webentwickler, API-Designer, Systemadministratoren und alle, die mit Webtechnologien arbeiten, unerlässlich. Statuscodes ermöglichen es Clients – ob Browser, mobile Apps oder andere Server – zu verstehen, was mit ihrer Anfrage passiert ist und wie sie fortfahren sollen.
Wie HTTP-Statuscodes funktionieren
Wenn ein Client eine HTTP-Anfrage an einen Server sendet, antwortet der Server mit einem dreistelligen Statuscode, gefolgt von einer menschenlesbaren Begründung (Reason Phrase). Die erste Ziffer des Statuscodes definiert die Klasse der Antwort. Die restlichen zwei Ziffern haben keine spezifische Kategorisierungsrolle, sondern bieten Granularität innerhalb jeder Klasse. Statuscodes werden von der Internet Assigned Numbers Authority (IANA) basierend auf Spezifikationen definiert, die in RFC-Dokumenten veröffentlicht wurden. Stand 2025 gibt es über 70 offiziell registrierte HTTP-Statuscodes, obwohl nur etwa 30-40 häufig verwendet werden.
Kurzreferenz
| Klasse | Kategorie | Bedeutung |
|---|---|---|
| 1xx | Informativ | Anfrage erhalten, Verarbeitung läuft |
| 2xx | Erfolg | Anfrage empfangen, verstanden und akzeptiert |
| 3xx | Weiterleitung | Weitere Maßnahmen erforderlich, um die Anfrage abzuschließen |
| 4xx | Client-Fehler | Anfrage enthält fehlerhafte Syntax oder kann nicht erfüllt werden |
| 5xx | Server-Fehler | Server konnte eine gültige Anfrage nicht erfüllen |
1xx - Informativ
Diese Codes zeigen an, dass der Server die Anfrageheader erhalten hat und der Client den Body weiter senden sollte, oder dass der Server zu einem anderen Protokoll wechselt. Es handelt sich um vorläufige Antworten ohne tatsächlichen Body-Inhalt.
| Code | Name | Beschreibung |
|---|---|---|
| 100 | Continue | Server hat Header erhalten, Client sollte Body weiter senden |
| 101 | Switching Protocols | Server wechselt das Protokoll (z. B. Upgrade auf WebSocket) |
| 102 | Processing | Server verarbeitet die Anfrage, aber noch keine Antwort (WebDAV) |
| 103 | Early Hints | Ressourcen vorladen, während Server Antwort vorbereitet, für Leistungsoptimierung |
Der Status 100 Continue wird oft in Verbindung mit dem Expect: 100-continue-Anfrageheader verwendet. Wenn ein Client diesen Header sendet, wartet er auf eine Bestätigung, bevor er eine große Nutzlast sendet. Dies verhindert Bandbreitenverschwendung, wenn der Server die Anfrage bereits aufgrund der Header ablehnen wird.
101 Switching Protocols ist der Eckpfeiler von WebSocket-Verbindungen. Wenn ein Client einen Upgrade: websocket-Header sendet, antwortet der Server mit 101, um den Protokollwechsel von HTTP zu WebSocket zu bestätigen, was eine Echtzeit-Bidirektionale Kommunikation ermöglicht.
103 Early Hints ist eine relativ neue Ergänzung (RFC 8297), die es Servern ermöglicht, dem Browser Hinweise auf kritische Ressourcen (CSS, JavaScript, Schriftarten) zu senden, die für die endgültige Antwort benötigt werden. Dies ermöglicht es dem Browser, diese Ressourcen vorzuladen, bevor die vollständige Antwort bereit ist, was die wahrgenommene Leistung verbessert.
2xx - Erfolg
Diese Codes zeigen an, dass die Anfrage des Clients erfolgreich empfangen, verstanden und akzeptiert wurde. Dies ist die Kategorie, die jeder Entwickler zu sehen hofft.
| Code | Name | Beschreibung |
|---|---|---|
| 200 | OK | Standard-Erfolgsantwort für GET-, POST-, PUT-Anfragen |
| 201 | Created | Ressource erfolgreich erstellt, typischerweise als Antwort auf POST |
| 202 | Accepted | Anfrage zur Verarbeitung angenommen, aber noch nicht abgeschlossen |
| 203 | Non-Authoritative Info | Antwort von einer Drittanbieterquelle, nicht vom Ursprungsserver |
| 204 | No Content | Erfolg, aber kein Antwort-Body zurückzugeben |
| 205 | Reset Content | Teilt Browser mit, das aktuelle Formular/Dokument zu löschen |
| 206 | Partial Content | Teilweise Ressource zurückgegeben, für Bereichsanfragen und fortsetzbare Downloads |
| 207 | Multi-Status | Mehrere Statuscodes für mehrere Ressourcen (WebDAV) |
| 208 | Already Reported | Ressource wurde bereits gemeldet (WebDAV) |
200 OK ist der häufigste Statuscode. Er zeigt an, dass die Anfrage erfolgreich war und der Antwort-Body die angeforderten Daten enthält. Bei GET-Anfragen enthält der Body die Ressourcendarstellung. Bei POST-Anfragen enthält er das Ergebnis der Aktion.
201 Created sollte zurückgegeben werden, wenn eine neue Ressource als Ergebnis einer POST- oder PUT-Anfrage erstellt wurde. Die Antwort sollte einen Location-Header enthalten, der auf die URL der neu erstellten Ressource verweist. Nach dem Erstellen eines neuen Benutzers geben Sie beispielsweise 201 Created mit der Profil-URL des Benutzers im Location-Header zurück.
204 No Content ist nützlich für DELETE-Anfragen oder PUT-Updates, bei denen der Antwort-Body leer ist. Es teilt dem Client mit, dass die Operation erfolgreich war, aber nichts zurückzugeben ist. Der Browser sollte seine aktuelle Dokumentansicht nicht ändern.
3xx - Weiterleitung
Diese Codes zeigen an, dass der Client zusätzliche Maßnahmen ergreifen muss, um die Anfrage abzuschließen, normalerweise durch Befolgen einer Weiterleitung zu einer anderen URL.
| Code | Name | Beschreibung |
|---|---|---|
| 300 | Multiple Choices | Mehrere mögliche Darstellungen, Client sollte wählen |
| 301 | Moved Permanently | Ressource hat eine neue permanente URL, Lesezeichen aktualisieren |
| 302 | Found | Temporäre Weiterleitung, ursprüngliche URL weiterhin verwenden |
| 303 | See Other | Weiterleitung zu einer anderen URL mit GET-Methode |
| 304 | Not Modified | Ressource nicht geändert, zwischengespeicherte Version verwenden |
| 307 | Temporary Redirect | Temporäre Weiterleitung unter Beibehaltung der HTTP-Methode |
| 308 | Permanent Redirect | Permanente Weiterleitung unter Beibehaltung der HTTP-Methode |
Die Unterscheidung zwischen 301 und 302 ist für SEO kritisch. Suchmaschinen behandeln 301-Weiterleitungen als permanent und übertragen die Ranking-Power der ursprünglichen URL auf die neue URL. Eine 302-Weiterleitung überträgt keinen SEO-Wert, da die ursprüngliche URL voraussichtlich zurückkehrt.
304 Not Modified wird in Verbindung mit bedingten Anfrageheadern wie If-Modified-Since oder If-None-Match (ETags) verwendet. Wenn der Client eine zwischengespeicherte Version einer Ressource hat, kann er den Server fragen, ob sich die Ressource geändert hat. Wenn nicht, gibt der Server 304 ohne Body zurück, was Bandbreite auf beiden Seiten spart.
307 und 308 bewahren die HTTP-Methode, die in der ursprünglichen Anfrage verwendet wurde, im Gegensatz zu 302 und 301, die POST in GET ändern können. Diese Unterscheidung ist für API-Endpunkte wichtig, bei denen die Beibehaltung der Anfragemethode wichtig ist.
4xx - Client-Fehler
Diese Codes zeigen an, dass der Client eine problematische Anfrage gesendet hat. Der Fehler liegt auf der Client-Seite – der Server arbeitet korrekt.
| Code | Name | Beschreibung |
|---|---|---|
| 400 | Bad Request | Ungültige Anfragesyntax oder -parameter |
| 401 | Unauthorized | Authentifizierung erforderlich oder fehlgeschlagen |
| 402 | Payment Required | Für zukünftige Verwendung reserviert, selten implementiert |
| 403 | Forbidden | Client authentifiziert, hat aber keine Berechtigung |
| 404 | Not Found | Die angeforderte Ressource existiert nicht |
| 405 | Method Not Allowed | HTTP-Methode wird für diese URL nicht unterstützt |
| 406 | Not Acceptable | Kann keine Antwort passend zu Accept-Headern erzeugen |
| 407 | Proxy Authentication | Muss sich zuerst beim Proxy authentifizieren |
| 408 | Request Timeout | Server hat beim Warten auf die Anfrage eine Zeitüberschreitung |
| 409 | Conflict | Anfrage steht im Konflikt mit aktuellem Serverzustand |
| 410 | Gone | Ressource dauerhaft gelöscht, keine Weiterleitungsadresse |
| 411 | Length Required | Content-Length-Header ist erforderlich |
| 412 | Precondition Failed | Bedingte Anfrageheader wurden als falsch ausgewertet |
| 413 | Payload Too Large | Anfragebody überschreitet Serverlimits |
| 414 | URI Too Long | URL überschreitet die maximal zulässige Länge des Servers |
| 415 | Unsupported Media Type | Content-Type wird vom Server nicht unterstützt |
| 416 | Range Not Satisfiable | Range-Header kann nicht erfüllt werden |
| 417 | Expectation Failed | Expect-Header kann nicht erfüllt werden |
| 422 | Unprocessable Entity | Anfragebody ist syntaktisch korrekt, aber semantisch ungültig |
| 423 | Locked | Ressource ist gesperrt (WebDAV) |
| 424 | Failed Dependency | Anfrage fehlgeschlagen, weil eine andere Anfrage fehlschlug (WebDAV) |
| 426 | Upgrade Required | Client sollte zu einem anderen Protokoll wechseln |
| 428 | Precondition Required | Ursprungsserver erfordert, dass die Anfrage bedingt ist |
| 429 | Too Many Requests | Client hat Rate-Limits überschritten |
| 431 | Request Header Too Large | Header überschreiten maximale Größe |
| 451 | Unavailable For Legal Reasons | Ressource aufgrund rechtlicher Anforderungen blockiert |
400 Bad Request ist der Sammelbegriff für Client-Fehler. Verwenden Sie ihn, wenn der Server die Anfrage aufgrund fehlerhafter Syntax, ungültiger Abfrageparameter oder eines fehlerhaften Anfragebodys nicht verarbeiten kann. Fügen Sie immer eine beschreibende Fehlermeldung im Antwort-Body hinzu, um Clients bei der Behebung des Problems zu helfen.
401 Unauthorized wird zurückgegeben, wenn der Client keine gültigen Authentifizierungsdaten vorgelegt hat. Die Antwort sollte einen WWW-Authenticate-Header enthalten, der das Authentifizierungsschema (Basic, Bearer, Digest usw.) angibt, das der Server erwartet.
403 Forbidden unterscheidet sich von 401 darin, dass der Client authentifiziert ist, aber nicht über ausreichende Berechtigungen verfügt. Ein normaler Benutzer, der versucht, auf einen Admin-Endpunkt zuzugreifen, sollte beispielsweise 403 erhalten, nicht 401.
404 Not Found ist der bekannteste HTTP-Statuscode. Er zeigt an, dass der Server die angeforderte Ressource nicht finden kann. Achten Sie darauf, nicht preiszugeben, ob die Ressource existiert, aber versteckt ist – die Rückgabe von 404 sowohl für nicht vorhandene als auch für versteckte Ressourcen ist eine gängige Sicherheitspraxis.
409 Conflict ist nützlich für REST-APIs bei einem Versionskonflikt. Zum Beispiel, wenn eine PUT-Anfrage eine Ressource aktualisiert, die seit dem letzten Abruf durch den Client von einem anderen Benutzer geändert wurde.
429 Too Many Requests ist für das API-Rate-Limiting unerlässlich. Es sollte einen Retry-After-Header enthalten, der angibt, wie lange der Client warten soll, bevor er eine weitere Anfrage stellt.
5xx - Server-Fehler
Diese Codes zeigen an, dass der Server bei der Verarbeitung einer gültigen Anfrage auf einen Fehler gestoßen ist. Das Problem liegt auf der Serverseite.
| Code | Name | Beschreibung |
|---|---|---|
| 500 | Internal Server Error | Generischer Serverfehler, keine spezifischen Details verfügbar |
| 501 | Not Implemented | Server unterstützt die angeforderte Funktionalität nicht |
| 502 | Bad Gateway | Upstream-Server hat eine ungültige Antwort zurückgegeben |
| 503 | Service Unavailable | Server vorübergehend nicht verfügbar (überlastet oder ausgefallen) |
| 504 | Gateway Timeout | Upstream-Server hat nicht rechtzeitig geantwortet |
| 505 | HTTP Version Not Supported | Server unterstützt die verwendete HTTP-Protokollversion nicht |
| 506 | Variant Also Negotiates | Serverkonfigurationsfehler in der Inhaltsaushandlung |
| 507 | Insufficient Storage | Server kann die Darstellung nicht speichern (WebDAV) |
| 508 | Loop Detected | Server hat eine Endlosschleife erkannt (WebDAV) |
| 509 | Bandwidth Limit Exceeded | Kein offizieller Status, von einigen Apache-Modulen verwendet |
| 510 | Not Extended | Weitere Erweiterungen für die Anfrage erforderlich |
| 511 | Network Authentication Required | Client muss sich authentifizieren, um auf das Netzwerk zuzugreifen |
500 Internal Server Error ist der Sammelbegriff für serverseitige Fehler. Er sollte niemals für ungültige Client-Anfragen zurückgegeben werden – dafür sollten 4xx-Codes verwendet werden. Eine 500-Antwort zeigt an, dass in der Verarbeitungslogik des Servers etwas schiefgelaufen ist.
502 Bad Gateway tritt typischerweise auf, wenn ein Proxy oder Load Balancer eine ungültige Antwort von einem Upstream-Server erhält. Wenn beispielsweise ein Anwendungsserver abstürzt oder eine fehlerhafte Antwort zurückgibt, gibt der Reverse-Proxy 502 an den Client zurück.
503 Service Unavailable wird verwendet, wenn der Server vorübergehend überlastet oder wegen Wartungsarbeiten nicht verfügbar ist. Fügen Sie einen Retry-After-Header hinzu, damit Clients und Crawler wissen, wann sie es erneut versuchen sollen. Dies wird häufig während Bereitstellungsfenstern oder Verkehrsspitzen gesehen.
504 Gateway Timeout tritt auf, wenn ein Server in einer Kette (z. B. ein Reverse-Proxy, der mit einem Anwendungsserver spricht) keine rechtzeitige Antwort von einem anderen Server erhält. Das Standard-Timeout beträgt je nach Infrastruktur typischerweise 30-120 Sekunden.
Leitfaden zur Verwendung von Statuscodes
| Szenario | Statuscode |
|---|---|
| Erfolgreiche GET-Anfrage | 200 |
| Erfolgreiches POST (erstellt) | 201 |
| Erfolgreiches DELETE | 204 |
| Formularvalidierung fehlschlägt | 422 |
| Benutzer nicht eingeloggt | 401 |
| Benutzer fehlt Berechtigung | 403 |
| Ressource nicht gefunden | 404 |
| Rate-Limit überschritten | 429 |
| Serverabsturz | 500 |
| API-Endpunkt noch nicht implementiert | 501 |
| Vorübergehende Wartung | 503 |
Best Practices für die Verwendung von HTTP-Statuscodes
Verwenden Sie immer den spezifischsten Statuscode, der auf Ihre Situation zutrifft. Die Rückgabe eines generischen 500-Fehlers, wenn ein 503 oder 504 angemessener wäre, erschwert das Debugging für API-Konsumenten. Fügen Sie beschreibende Fehlermeldungen und eindeutige Fehlerkennungen in Ihre Antwort-Bodies ein, um das Debugging zu erleichtern. Für REST-APIs sollten Sie auch einen maschinenlesbaren Fehlercode in Betracht ziehen, den Clients programmatisch verarbeiten können. Stellen Sie schließlich sicher, dass Ihre Fehlerantworten den durch Inhaltsaushandlung angeforderten Inhaltstyp respektieren – geben Sie JSON für API-Clients und HTML für browserbasierte Fehlerseiten zurück.
Verwenden Sie das Tool HTTP Status Code Reference für schnelle Nachschlagevorgänge, wenn Sie die Bedeutung oder die korrekte Verwendung eines HTTP-Statuscodes abrufen müssen.
