Ihre Sticker

Heften Sie hier Tools an. Sie werden in diesem Browser gespeichert.

HTTP-Statuscodes im Überblick

Die HTTP-Statuscodes von 100 bis 511, jeweils mit ihrer Bedeutung für Entwickler und dem RFC, der sie definiert, dazu nicht standardisierte Codes von nginx, Cloudflare und anderen Produkten.

78 Statuscodes.

1xx Information

Der Server hat die Anfrage erhalten und bearbeitet sie noch. Es handelt sich um Zwischenantworten, die vor der endgültigen Antwort gesendet werden.

100 Continue: Der Server hat die Header der Anfrage erhalten, und der Client kann den Body senden. Ein Client fordert das an, indem er vor einem großen Upload Expect: 100-continue sendet. RFC 9110
101 Switching Protocols: Der Server willigt ein, das Protokoll dieser Verbindung zu wechseln, wie es der Upgrade-Header verlangt. So beginnt eine WebSocket-Verbindung. RFC 9110
102 Processing: Der Server hat eine WebDAV-Anfrage angenommen und bearbeitet sie noch, damit der Client nicht in ein Timeout läuft. Die aktuelle WebDAV-Spezifikation enthält den Code nicht mehr, und er wird selten gesendet. RFC 2518
103 Early Hints: Wird vor der endgültigen Antwort mit Link-Headern gesendet, damit der Browser schon Ressourcen vorladen oder Verbindungen öffnen kann, während der Server die Seite vorbereitet. RFC 8297

2xx Erfolg

Die Anfrage wurde empfangen, verstanden und angenommen.

200 OK: Die Anfrage war erfolgreich. Der Body enthält das Ergebnis: bei GET die Ressource, bei POST das Ergebnis der Aktion. RFC 9110
201 Created: Die Anfrage hat eine neue Ressource angelegt. Deren URL steht meist im Location-Header. RFC 9110
202 Accepted: Die Anfrage wurde zur Verarbeitung angenommen, die noch nicht abgeschlossen ist und noch fehlschlagen kann. Typisch für Aufgaben, die in eine Warteschlange gestellt werden. RFC 9110
203 Non-Authoritative Information: Die Anfrage war erfolgreich, aber ein Proxy hat die Antwort des Ursprungsservers verändert. RFC 9110
204 No Content: Die Anfrage war erfolgreich, und es gibt keinen Body zu senden. Üblich bei DELETE sowie bei PUT oder PATCH, wenn der Client den neuen Zustand bereits kennt. RFC 9110
205 Reset Content: Die Anfrage war erfolgreich, und der Client soll die Ansicht zurücksetzen, von der sie kam, zum Beispiel ein Formular leeren. Es gibt keinen Body. RFC 9110
206 Partial Content: Der Body enthält nur den Bytebereich, den der Range-Header angefordert hat. Wird genutzt, um Downloads fortzusetzen und in Videos zu springen. RFC 9110
207 Multi-Status: Der Body ist ein XML-Dokument mit einem eigenen Status für jede von mehreren Ressourcen. WebDAV verwendet ihn. RFC 4918
208 Already Reported: Innerhalb einer WebDAV-Multi-Status-Antwort markiert er die Mitglieder eines Bindings, die bereits aufgeführt wurden, damit sie nicht wiederholt werden. RFC 5842
226 IM Used: Der Body ist das Ergebnis einer oder mehrerer Instance Manipulations, etwa eines Deltas, angewendet auf die aktuelle Ressource. Er gehört zum Delta Encoding in HTTP, das selten implementiert wird. RFC 3229

3xx Weiterleitung

Der Client muss einen weiteren Schritt ausführen, um die Anfrage abzuschließen, meist eine Anfrage an eine andere URL.

300 Multiple Choices: Die Ressource hat mehrere Repräsentationen, und der Client kann eine davon wählen. Wird selten verwendet, weil es kein standardisiertes Verfahren für die Auswahl gibt. RFC 9110
301 Moved Permanently: Dauerhafte Weiterleitung: Die Ressource hat eine neue URL, die im Location-Header steht, und Suchmaschinen indexieren in der Regel diese URL an ihrer Stelle. Clients dürfen beim Folgen der Weiterleitung POST in GET ändern; mit 308 bleibt die Methode erhalten. RFC 9110
302 Found: Vorübergehende Weiterleitung: Die Ressource liegt vorerst unter einer anderen URL, die im Location-Header steht. Clients dürfen beim Folgen der Weiterleitung POST in GET ändern; mit 307 bleibt die Methode erhalten. RFC 9110
303 See Other: Die Antwort liegt unter einer anderen URL, die der Client mit GET abrufen soll. Das ist die übliche Weiterleitung nach einem per POST gesendeten Formular, damit ein Neuladen der Seite das Formular nicht erneut absendet. RFC 9110
304 Not Modified: Die Kopie im Cache des Clients ist noch aktuell, daher wird kein Body gesendet. Antwort auf eine bedingte Anfrage mit If-None-Match oder If-Modified-Since. RFC 9110
305 Use Proxy: Die Ressource muss über den im Location-Header genannten Proxy abgerufen werden. Der Code ist aus Sicherheitsgründen veraltet, und Clients sollten sich nicht auf ihn verlassen. RFC 9110
306 (Unused): Eine frühere Version der Spezifikation verwendete diesen Code. Er wird nicht mehr verwendet, die Nummer bleibt aber reserviert. RFC 9110
307 Temporary Redirect: Die Ressource liegt vorübergehend unter einer anderen URL, und der Client muss der Weiterleitung mit derselben Methode und demselben Body folgen. RFC 9110
308 Permanent Redirect: Die Ressource hat eine neue dauerhafte URL, und der Client muss der Weiterleitung mit derselben Methode und demselben Body folgen. RFC 9110

4xx Client-Fehler

Der Fehler liegt beim Client: Die Anfrage ist fehlerhaft, es fehlt die Berechtigung, oder sie verlangt etwas, das nicht ausgeliefert werden kann.

400 Bad Request: Der Server kann die Anfrage nicht verarbeiten, weil sie fehlerhaft ist: Die Syntax ist falsch, das Framing ungültig oder der Body lässt sich nicht parsen. RFC 9110
401 Unauthorized: Der Anfrage fehlen gültige Zugangsdaten. Der WWW-Authenticate-Header der Antwort gibt an, wie man sich authentifiziert. Trotz des Namens geht es um Authentifizierung, nicht um Berechtigung. RFC 9110
402 Payment Required: Für künftige Verwendung reserviert. Manche APIs senden ihn, wenn ein Abonnement abgelaufen oder ein bezahltes Kontingent aufgebraucht ist. RFC 9110
403 Forbidden: Der Server hat die Anfrage verstanden und verweigert sie. Falls die Anfrage Zugangsdaten enthielt, gewähren diese keinen Zugriff auf diese Ressource, und sie erneut zu senden hilft nicht. RFC 9110
404 Not Found: Der Server hat unter dieser URL nichts oder will nicht verraten, dass er etwas hat. Der Code sagt nicht, ob das Fehlen dauerhaft ist. RFC 9110
405 Method Not Allowed: Die Ressource existiert, unterstützt diese Methode aber nicht. Der Allow-Header listet die Methoden auf, die sie unterstützt. RFC 9110
406 Not Acceptable: Der Server kann keine Antwort erzeugen, die den Headern Accept, Accept-Language oder Accept-Encoding der Anfrage entspricht. RFC 9110
407 Proxy Authentication Required: Wie 401, aber der Client muss sich beim Proxy authentifizieren, wie im Proxy-Authenticate-Header beschrieben. RFC 9110
408 Request Timeout: Der Server hat die vollständige Anfrage nicht innerhalb der Zeit erhalten, die er zu warten bereit war, und schließt die Verbindung. RFC 9110
409 Conflict: Die Anfrage steht im Konflikt mit dem aktuellen Zustand der Ressource, etwa eine Änderung auf Basis einer veralteten Version oder das Duplikat eines eindeutigen Werts. RFC 9110
410 Gone: Die Ressource war früher hier und wurde endgültig entfernt. Anders als 404 teilt er Clients und Suchmaschinen mit, dass sie die URL verwerfen können. RFC 9110
411 Length Required: Der Server lehnt die Anfrage ab, weil sie keinen Content-Length-Header hat. RFC 9110
412 Precondition Failed: Eine Bedingung in If-Match, If-Unmodified-Since oder einem ähnlichen Header war nicht erfüllt, daher wurde die Anfrage nicht ausgeführt. Das schützt davor, die Änderung eines anderen zu überschreiben. RFC 9110
413 Content Too Large: Der Body der Anfrage ist größer, als der Server akzeptiert, meist wegen eines Upload-Limits im Server oder in einem vorgeschalteten Proxy. Früher hieß der Code Payload Too Large. RFC 9110
414 URI Too Long: Die URL ist länger, als der Server akzeptiert. Oft bedeutet das, dass Daten, die in einen POST-Body gehören, im Query-String gelandet sind. RFC 9110
415 Unsupported Media Type: Der Server akzeptiert das Format des Bodys nicht, das im Content-Type- oder Content-Encoding-Header der Anfrage angegeben ist. RFC 9110
416 Range Not Satisfiable: Der Range-Header fordert Bytes an, die außerhalb der Ressource liegen. RFC 9110
417 Expectation Failed: Der Server kann die Anforderung aus dem Expect-Header der Anfrage nicht erfüllen. RFC 9110
418 I'm a teapot: Ein Aprilscherz aus dem Hyper Text Coffee Pot Control Protocol, in dem sich eine Teekanne weigert, Kaffee zu kochen. RFC 9110 führt die Nummer als ungenutzt und hält sie reserviert, weil sie zu oft als Scherz implementiert wurde, um ihr eine andere Bedeutung zu geben. RFC 2324, RFC 9110
421 Misdirected Request: Die Anfrage hat einen Server erreicht, der nicht dafür konfiguriert ist, für diesen Hostnamen zu antworten. Das kann passieren, wenn ein Browser eine HTTP/2-Verbindung für einen anderen Host wiederverwendet; der Client kann es über eine neue Verbindung erneut versuchen. RFC 9110
422 Unprocessable Content: Die Syntax der Anfrage ist korrekt, aber ihr Inhalt ist ungültig, zum Beispiel ein JSON-Body, der die Validierung nicht besteht. Der Code stammt aus WebDAV, wo er Unprocessable Entity hieß. RFC 9110, RFC 4918
423 Locked: Die WebDAV-Ressource ist gesperrt, daher kann die Methode nicht auf sie angewendet werden. RFC 4918
424 Failed Dependency: Die Methode wurde auf dieser WebDAV-Ressource nicht ausgeführt, weil eine andere Aktion, von der sie abhing, fehlgeschlagen ist. RFC 4918
425 Too Early: Der Server verarbeitet keine Anfrage, die als TLS Early Data ankam, weil sie ein Replay sein könnte. Der Client soll sie nach Abschluss des Handshakes erneut senden. RFC 8470
426 Upgrade Required: Der Server lehnt die Anfrage über dieses Protokoll ab und nennt im Upgrade-Header das Protokoll, zu dem der Client wechseln muss. RFC 9110
428 Precondition Required: Der Server verlangt eine bedingte Anfrage, etwa mit If-Match, damit ein Update nicht unbemerkt eine neuere Version überschreibt. RFC 6585
429 Too Many Requests: Der Client hat in einem bestimmten Zeitraum zu viele Anfragen gesendet; das nennt man Rate Limiting. Der Retry-After-Header kann angeben, wie lange er warten soll. RFC 6585
431 Request Header Fields Too Large: Die Header sind insgesamt oder einzeln größer, als der Server akzeptiert. Eine häufige Ursache ist ein zu großes Cookie. RFC 6585
451 Unavailable For Legal Reasons: Der Server verweigert den Zugriff aufgrund einer rechtlichen Forderung, etwa eines Gerichtsbeschlusses. Die Nummer spielt auf den Roman Fahrenheit 451 an. RFC 7725

5xx Server-Fehler

Die Anfrage mag gültig sein, aber der Server oder ein vorgeschaltetes Gateway konnte sie nicht erfüllen.

500 Internal Server Error: Der Server ist auf einen unerwarteten Zustand gestoßen, oft eine nicht behandelte Exception. Die Ursache findet sich in den Logs des Servers. RFC 9110
501 Not Implemented: Der Server unterstützt die Funktion nicht, die die Anfrage benötigt, zum Beispiel eine Methode, die er nicht kennt. RFC 9110
502 Bad Gateway: Ein Gateway oder Proxy hat vom dahinterliegenden Server eine ungültige Antwort erhalten. Oft ist die Anwendung hinter dem Proxy abgestürzt oder lauscht nicht. RFC 9110
503 Service Unavailable: Der Server kann die Anfrage wegen Überlastung oder Wartung im Moment nicht bearbeiten. Der Retry-After-Header kann angeben, wann ein neuer Versuch sinnvoll ist. RFC 9110
504 Gateway Timeout: Ein Gateway oder Proxy hat vom dahinterliegenden Server nicht rechtzeitig eine Antwort erhalten. Oft ist die Anwendung zu langsam oder nicht erreichbar. RFC 9110
505 HTTP Version Not Supported: Der Server unterstützt die HTTP-Hauptversion nicht, die die Anfrage verwendet. RFC 9110
506 Variant Also Negotiates: Der Server ist falsch konfiguriert: Die per transparenter Content Negotiation gewählte Variante ist selbst wieder zum Aushandeln eingerichtet, was eine Schleife ergibt. RFC 2295
507 Insufficient Storage: Der Server kann nicht speichern, was er zum Abschließen der Anfrage braucht. Der Code ist für WebDAV definiert. RFC 4918
508 Loop Detected: Der Server hat eine WebDAV-Operation abgebrochen, weil er beim Verfolgen von Bindings auf eine Endlosschleife gestoßen ist. RFC 5842
510 Not Extended: Der Anfrage fehlt eine Erweiterung, die der Server verlangt. Die Spezifikation, die den Code definiert hat, gilt inzwischen als historisch, und das IANA-Register führt den Code als obsolet. RFC 2774
511 Network Authentication Required: Der Client muss sich authentifizieren, um Zugang zum Netzwerk zu erhalten. Gesendet wird der Code von einem Captive Portal, etwa der Anmeldeseite eines Hotel-WLANs, und nicht von der angefragten Website. RFC 6585

Nicht standardisierte Codes

Diese Codes stehen nicht im IANA-Register. Jeder von ihnen wird von einem bestimmten Server oder Dienst verwendet, und seine Bedeutung gilt nur dort.

419 Page Expired Nicht standardisiert: Laravel sendet ihn, wenn das CSRF-Token eines Formulars fehlt oder abgelaufen ist. Laravel
444 No Response Nicht standardisiert: Eine nginx-Konfiguration kann 444 zurückgeben, um die Verbindung zu schließen, ohne eine Antwort zu senden. Der Code erscheint im nginx-Log, der Client erhält nichts. nginx
494 Request Header Too Large Nicht standardisiert: nginx verwendet ihn intern, wenn die Header der Anfrage nicht in seine Puffer passen. Der Client erhält eine 400-Antwort. nginx
495 SSL Certificate Error Nicht standardisiert: nginx verwendet ihn intern, wenn die Prüfung eines Client-Zertifikats fehlschlägt. Sofern die Konfiguration das nicht abfängt, erhält der Client eine 400-Antwort. nginx
496 SSL Certificate Required Nicht standardisiert: nginx verwendet ihn intern, wenn der Client das vom Server verlangte Zertifikat nicht vorgelegt hat. nginx
497 HTTP Request Sent to HTTPS Port Nicht standardisiert: nginx verwendet ihn intern, wenn eine einfache HTTP-Anfrage an einem Port ankommt, der HTTPS erwartet. nginx
499 Client Closed Request Nicht standardisiert: nginx protokolliert ihn, wenn der Client die Verbindung geschlossen hat, bevor der Server geantwortet hat. Oft ist das Timeout des Clients kürzer als die Zeit, die die Anwendung braucht. nginx
509 Bandwidth Limit Exceeded Nicht standardisiert: Hosting-Control-Panels wie cPanel senden ihn, wenn eine Website ihr Bandbreitenkontingent aufgebraucht hat. cPanel
520 Web Server Returned an Unknown Error Nicht standardisiert: Cloudflare sendet ihn, wenn der Ursprungsserver eine leere, unbekannte oder unerwartete Antwort geliefert hat. Cloudflare
521 Web Server Is Down Nicht standardisiert: Cloudflare sendet ihn, wenn der Ursprungsserver die Verbindung abgelehnt hat. Cloudflare
522 Connection Timed Out Nicht standardisiert: Cloudflare sendet ihn, wenn es eine TCP-Verbindung zum Ursprungsserver nicht rechtzeitig aufbauen konnte. Cloudflare
523 Origin Is Unreachable Nicht standardisiert: Cloudflare sendet ihn, wenn es den Ursprungsserver nicht erreichen konnte, etwa wegen eines falschen DNS-Eintrags oder eines Routing-Problems. Cloudflare
524 A Timeout Occurred Nicht standardisiert: Cloudflare hat sich mit dem Ursprungsserver verbunden, aber dieser hat nicht rechtzeitig eine HTTP-Antwort gesendet. Cloudflare
525 SSL Handshake Failed Nicht standardisiert: Cloudflare sendet ihn, wenn der TLS-Handshake zwischen Cloudflare und dem Ursprungsserver fehlgeschlagen ist. Cloudflare
526 Invalid SSL Certificate Nicht standardisiert: Cloudflare sendet ihn, wenn es das TLS-Zertifikat des Ursprungsservers nicht validieren konnte. Cloudflare

Über dieses Tool

Wie Statuscodes aufgebaut sind

Jede HTTP-Antwort beginnt mit einem dreistelligen Statuscode. Die erste Ziffer gibt die Klasse an: 1xx ist eine Zwischenantwort, 2xx bedeutet Erfolg, 3xx schickt den Client woandershin, 4xx heißt, der Fehler lag bei der Anfrage, und 5xx, er lag beim Server. Ein Client, der einen Code nicht kennt, muss ihn wie den ersten Code seiner Klasse behandeln; ein unbekannter 4xx-Code wird also wie 400 behandelt.

Der Text nach der Zahl, etwa Not Found, ist die Reason Phrase. Sie ist nur eine Beschreibung für Menschen: Clients sollen sie ignorieren, und HTTP/2 und HTTP/3 senden sie gar nicht erst. Die Namen der Standardcodes in dieser Liste sind die aus dem IANA-Register, außer bei 418, den das Register als (Unused) führt.

Codes, die oft verwechselt werden

401 und 403. 401 bedeutet, dass der Server nicht weiß, wer Sie sind, und eine Authentifizierung helfen kann. 403 bedeutet, dass der Server die Anfrage verweigert und eine erneute Authentifizierung an der Antwort nichts ändert.

301, 302, 307 und 308. 301 und 308 sind dauerhaft, 302 und 307 vorübergehend. Bei 301 und 302 darf ein Client beim Folgen der Weiterleitung aus einem POST ein GET machen; 307 und 308 verlangen dieselbe Methode und denselben Body.

502 und 504. Beide kommen von einem Proxy oder Load Balancer vor der Anwendung. Bei 502 hat der Proxy etwas Ungültiges erhalten oder die Verbindung ist gescheitert; bei 504 hat er gewartet und nicht rechtzeitig etwas erhalten.

404 und 410. 404 sagt, dass hier nichts ist, vielleicht nur vorübergehend. 410 sagt, dass die Ressource endgültig entfernt wurde.

Woher diese Liste stammt

Die Standardcodes stammen aus der IANA HTTP Status Code Registry. Die meisten sind in RFC 9110 (HTTP Semantics) definiert, der 2022 RFC 7231 abgelöst hat. Die übrigen stammen aus WebDAV und aus kleineren Erweiterungen, und bei jedem Eintrag steht sein RFC. Vorläufige Registrierungen, die noch Internet-Drafts sind, fehlen. Die letzte Gruppe enthält Codes, die nicht registriert sind, aber in den Logs und Fehlerseiten von nginx, Cloudflare und anderen Produkten auftauchen.

Die gesamte Liste ist Teil der Seite und lässt sich daher auch ohne JavaScript lesen. Das Suchfeld filtert sie in Ihrem Browser.

Fragen

Was ist der Unterschied zwischen 401 und 403?

401 Unauthorized bedeutet, dass die Anfrage keine gültigen Zugangsdaten enthält und der Client es nach einer Authentifizierung erneut versuchen kann. 403 Forbidden bedeutet, dass der Server die Anfrage verstanden hat und verweigert: Mitgesendete Zugangsdaten gewähren keinen Zugriff, sie erneut zu senden hilft also nicht.

Sollte eine dauerhafte Weiterleitung 301 oder 308 verwenden?

Beide teilen Clients und Suchmaschinen mit, dass die URL endgültig umgezogen ist. Bei 301 darf ein Client beim Folgen der Weiterleitung aus einem POST ein GET machen, während 308 dieselbe Methode und denselben Body verlangt. Für gewöhnliche Seiten-URLs, die mit GET abgerufen werden, verhalten sich beide gleich.

Was ist der Unterschied zwischen 502 und 504?

Beide werden von einem Proxy, Gateway oder Load Balancer gesendet, nicht von der Anwendung. 502 Bad Gateway bedeutet, dass der dahinterliegende Server eine ungültige Antwort geliefert oder die Verbindung abgelehnt hat. 504 Gateway Timeout bedeutet, dass er nicht innerhalb des Zeitlimits des Proxys geantwortet hat.

Ist 499 ein echter HTTP-Statuscode?

Er ist nicht bei der IANA registriert. nginx schreibt 499 in sein Access-Log, wenn der Client die Verbindung geschlossen hat, bevor die Antwort gesendet wurde; kein Client erhält ihn also je. Andere Produkte verwenden auf ähnliche Weise Nummern außerhalb des Registers, etwa 520 bis 526 bei Cloudflare.