Schlagen Sie beliebige HTTP-Statuscodes nach: ihre Bedeutung, wann Server sie senden und in welcher Spezifikation sie definiert sind. Suchen Sie nach Nummer oder Stichwort, filtern Sie nach Klasse und verlinken Sie direkt auf einen Statuscode.
Läuft in Ihrem Browser Keine Anmeldung erforderlich
Der Server hat die Anfrage-Header erhalten, und der Client kann den Anfragetext senden. Der Status tritt auf, wenn ein Client vor dem Hochladen eines großen Anfragetexts „Expect: 100-continue“ sendet.
Der Server stimmt dem Wechsel zu dem Protokoll zu, das der Client im Upgrade-Header angefordert hat. Der Status tritt auf, wenn eine Verbindung auf WebSocket umgestellt wird.
Der Server hat eine WebDAV-Anfrage angenommen, aber noch nicht abgeschlossen. Der Status wurde aus späteren WebDAV-Spezifikationen entfernt und wird heute nur selten verwendet.
Wird vor der endgültigen Antwort gesendet, damit der Browser mit dem Vorladen von Ressourcen aus Link-Headern beginnen kann. CDNs und Server verwenden den Status, um Seiten schneller zu laden.
Die Anfrage war erfolgreich und die Antwort enthält das Ergebnis. Dies ist die normale Antwort beim Laden einer Seite oder bei einem erfolgreichen API-Aufruf.
Die Anfrage war erfolgreich und hat eine neue Ressource erstellt, die üblicherweise über den Location-Header angegeben wird. Typisch nach einem erfolgreichen POST, der einen Datensatz erstellt.
Die Anfrage wurde zur Verarbeitung angenommen, ist aber noch nicht abgeschlossen. APIs verwenden den Status für Aufgaben in Warteschlangen, etwa Exporte oder Stapelverarbeitungsjobs.
Die Anfrage war erfolgreich, es gibt aber keine Inhalte zurückzugeben. Häufig bei DELETE-Anfragen und beim Speichern von Daten, wenn der Client keinen Antworttext benötigt.
Der Server gibt nur den angeforderten Byte-Bereich zurück. Der Status tritt beim Streamen von Videos, beim Fortsetzen von Downloads oder bei einer Range-Header-Angabe des Clients auf.
Wird innerhalb einer WebDAV-207-Antwort verwendet, damit bereits aufgeführte Mitglieder derselben gebundenen Ressource nicht erneut aufgelistet werden.
Die Ressource wurde dauerhaft zur URL im Location-Header verschoben. Browser und Suchmaschinen aktualisieren ihre Verweise; einige Clients ändern beim Folgen der Weiterleitung POST in GET.
Die Ressource befindet sich vorübergehend unter einer anderen URL, die im Location-Header angegeben ist. Häufig nach Anmeldungen und bei kurzfristigen Weiterleitungen; Browser folgen der Weiterleitung üblicherweise mit GET.
Der Client sollte das Ergebnis mit GET von einer anderen URL abrufen. Wird nach einem Formular-POST verwendet, um zu einer Bestätigungsseite weiterzuleiten (Post/Redirect/Get-Muster).
Die zwischengespeicherte Kopie ist weiterhin gültig, daher sendet der Server keinen Antworttext. Der Status tritt auf, wenn ein Browser eine zwischengespeicherte Datei mit If-None-Match oder If-Modified-Since erneut überprüft.
Der Client sollte einen im Location-Header angegebenen Proxy verwenden. Der Status ist aus Sicherheitsgründen veraltet und wird von Browsern ignoriert.
Die Ressource befindet sich vorübergehend unter einer anderen URL. Der Client muss die Anfrage mit derselben Methode und demselben Body wiederholen. Browser verwenden den Code auch für interne HSTS-Weiterleitungen zu HTTPS.
Die Ressource wurde dauerhaft verschoben. Der Client muss an der neuen URL dieselbe Methode und denselben Body verwenden. Das dauerhafte Gegenstück zu 307, geeignet für Weiterleitungen von POST-Anfragen.
Der Server kann die Anfrage nicht verarbeiten, weil sie fehlerhaft ist, etwa wegen ungültigem JSON, eines fehlerhaften Abfrageparameters oder eines beschädigten Cookies.
Der Anfrage fehlen gültige Authentifizierungsdaten. Trotz des Namens bedeutet der Code „nicht authentifiziert“; der Server sendet einen WWW-Authenticate-Header mit Angaben zur Anmeldung.
Für eine künftige Verwendung in der HTTP-Spezifikation reserviert. Einige APIs und Zahlungsdienste verwenden den Code, wenn eine Zahlung oder ein Abonnement erforderlich ist.
Der Server hat die Anfrage verstanden, lehnt sie aber ab. Eine erneute Anmeldung hilft nicht. Der Code tritt auf, wenn Berechtigungen fehlen, ein Verzeichnisindex deaktiviert ist oder eine Firewall den Client blockiert.
Der Server kann die angeforderte Ressource nicht finden. Meist handelt es sich um einen falsch eingegebenen oder veralteten Link, eine gelöschte Seite oder eine falsche API-Route.
Die Ressource existiert, unterstützt aber die verwendete HTTP-Methode nicht, etwa POST bei einer schreibgeschützten URL. Die Antwort führt die zulässigen Methoden im Allow-Header auf.
Ähnlich wie 401, aber der Client muss sich zuerst bei einem Proxy authentifizieren. Der Code tritt in Unternehmensnetzwerken mit authentifizierungspflichtigem Proxy auf.
Der Server hat beim Warten darauf, dass der Client die Anfrage vollständig sendet, eine Zeitüberschreitung erreicht. Der Code tritt bei langsamen oder unterbrochenen Verbindungen auf.
Die Anfrage steht im Konflikt mit dem aktuellen Zustand der Ressource, etwa bei einem Bearbeitungskonflikt oder beim Erstellen eines bereits vorhandenen Eintrags.
Die Ressource wurde dauerhaft entfernt und wird nicht wieder verfügbar sein. Anders als 404 weist der Code Suchmaschinen an, die URL schneller aus dem Index zu entfernen.
Eine Bedingung in den Anfrage-Headern, etwa If-Match, wurde nicht erfüllt. Der Code verhindert, dass eine Ressource überschrieben wird, die sich seit dem letzten Abruf durch den Client geändert hat.
Der Body der Anfrage ist größer als vom Server zugelassen. Der Code tritt auf, wenn eine Datei ein Limit überschreitet, etwa nginx's client_max_body_size.
Die URL ist länger, als der Server verarbeitet. Ursache ist meist ein Formular, das zu viele Daten per GET sendet, oder eine Weiterleitungsschleife, die ständig Parameter anhängt.
Ein Aprilscherz aus dem Jahr 1998: Im Hyper Text Coffee Pot Control Protocol weigert sich eine Teekanne, Kaffee zu brühen. HTTP reserviert den Code als ungenutzt, aber einige Server geben ihn als Easter Egg zurück oder weisen damit unerwünschte Bots ab.
Kein standardisierter Code. Laravel gibt ihn zurück, wenn das CSRF-Token eines Formulars fehlt oder abgelaufen ist, meist nach einer abgelaufenen Sitzung.
Die Anfrage hat einen Server erreicht, der für diesen Host keine Antwort liefern kann, etwa wenn eine HTTP/2-Verbindung für eine andere Domain wiederverwendet wird.
Die Anfrage ist korrekt formatiert, aber ihr Inhalt ist ungültig, etwa ein Formular, dessen Validierungsregeln nicht erfüllt sind. APIs verwenden den Code häufig für Validierungsfehler.
Der Client hat innerhalb eines bestimmten Zeitraums zu viele Anfragen gesendet. APIs verwenden den Code zur Ratenbegrenzung und fügen häufig einen Retry-After-Header mit dem Zeitpunkt für den nächsten Versuch hinzu.
Die Anfrage-Header sind zu groß, häufig wegen zu vieler oder übergroßer Cookies. Meist lässt sich das Problem durch Löschen der Cookies der Website beheben.
Kein standardisierter Code. nginx verwendet ihn intern, um die Verbindung ohne Antwort zu schließen, häufig um unerwünschten Datenverkehr abzuweisen. Clients erhalten diesen Code nie tatsächlich.
Die Ressource ist aus rechtlichen Gründen nicht verfügbar, etwa aufgrund einer gerichtlichen Anordnung oder staatlicher Zensur. Die Nummer ist eine Anspielung auf den Roman Fahrenheit 451.
Kein standardisierter Code. nginx protokolliert ihn, wenn der Client die Verbindung schließt, bevor der Server antwortet, etwa weil ein Nutzer eine langsame Seite abbricht oder auf Clientseite eine Zeitüberschreitung auftritt.
Beim Server ist ein unerwarteter Fehler aufgetreten, sodass er die Anfrage nicht abschließen konnte. Ein allgemeiner Fehler, verursacht durch einen Programmfehler, Absturz oder eine Fehlkonfiguration. Details stehen in den Serverprotokollen.
Ein Gateway oder Proxy hat vom Upstream-Server eine ungültige Antwort erhalten. Häufig ist die Anwendung hinter nginx oder einem Load Balancer abgestürzt oder wird gerade neu gestartet.
Der Server kann die Anfrage vorübergehend nicht verarbeiten, weil er überlastet ist oder wegen Wartungsarbeiten nicht verfügbar ist. Ein Retry-After-Header kann angeben, wann der nächste Versuch möglich ist.
Ein Gateway oder Proxy hat nicht rechtzeitig eine Antwort vom Upstream-Server erhalten. Tritt auf, wenn eine Backend-Anfrage zu lange dauert, etwa eine umfangreiche Datenbankabfrage.
Kein Standardcode. Wird von manchen Shared-Hosting-Konfigurationen (Apache-Module, cPanel) verwendet, wenn eine Website ihr Bandbreitenlimit überschreitet.
Für die Bearbeitung der Anfrage sind weitere Erweiterungen erforderlich. Der Code wurde in einer experimentellen Spezifikation definiert, die inzwischen historisch ist.
Der Client muss sich authentifizieren, um Zugang zum Netzwerk zu erhalten. Wird von Captive Portals in Hotel-, Flughafen- oder Café-WLANs gesendet, bevor Sie sich anmelden.
Kein Standardcode. Cloudflare gibt ihn zurück, wenn der Ursprungsserver die Verbindung abgelehnt hat – meist, weil der Webserver ausgefallen ist oder Cloudflares IP-Adressen blockiert.
Kein Standardcode. Cloudflare gibt ihn zurück, wenn zwar eine Verbindung zum Ursprungsserver hergestellt wurde, dieser aber nicht innerhalb des Zeitlimits eine HTTP-Antwort gesendet hat (standardmäßig 100 Sekunden).
Kein Standardcode. Cloudflare gibt ihn zurück, wenn das SSL-Zertifikat des Ursprungsservers ungültig ist und der SSL-Modus „Full (strict)“ aktiviert ist.
Definiert in Cloudflare
Anleitung
Geben Sie eine Statusnummer ein (zum Beispiel 404 oder nur 5 für alle Serverfehler) oder ein Stichwort wie „Weiterleitung“ oder „Timeout“.
Grenzen Sie die Liste mit dem Klassenfilter ein: Information, Erfolg, Weiterleitung, Clientfehler oder Serverfehler.
Über „Link kopieren“ können Sie einen direkten Link zu einem Statuscode teilen, zum Beispiel in einem Fehlerbericht.
So funktioniert es
Jede HTTP-Antwort beginnt mit einem dreistelligen Statuscode. Die erste Ziffer legt die Klasse fest: 1xx steht für informative Antworten, 2xx für Erfolg, 3xx für Weiterleitungen, 4xx für durch die Anfrage verursachte Fehler und 5xx für serverseitige Fehler. Clients, die einen bestimmten Code nicht erkennen, behandeln ihn wie den x00-Code seiner Klasse. Ein unbekannter 4xx-Code wird also wie 400 behandelt.
Die grundlegenden Codes sind in RFC 9110 (HTTP Semantics, 2022) definiert, der den älteren RFC 7231 ersetzt hat. Andere stammen aus Erweiterungen: WebDAV (RFC 4918), RFC 6585 für 428, 429, 431 und 511, RFC 7725 für 451 sowie RFC 8470 für 425. RFC 9110 hat außerdem zwei Codes umbenannt: 413 heißt jetzt „Content Too Large“ und 422 „Unprocessable Content“. Sie finden diese möglicherweise noch unter ihren alten Bezeichnungen „Payload Too Large“ und „Unprocessable Entity“.
Einige Codes, die in Protokollen auftauchen, sind überhaupt keine Standards. nginx verwendet 444 und 494–499 intern (499 zeigt an, dass ein Client die Verbindung abgebrochen hat, während er auf eine Antwort wartete), und Cloudflare gibt 520–526 zurück, wenn es keine ordnungsgemäße Antwort vom Ursprungsserver erhält. Diese Codes sind in der Liste als „Non-standard“ gekennzeichnet. Die Begründungen (wie „Not Found“) werden wie in den Spezifikationen auf Englisch angezeigt; HTTP/2 und HTTP/3 übertragen nur die Nummer.
Beispiele
301 oder 308 beim Umzug einer Website
Beide sind dauerhaft. Verwenden Sie 301 für gewöhnliche Seitenumzüge. Verwenden Sie 308, wenn Clients POST- oder PUT-Anfragen an die neue URL wiederholen müssen, da manche Clients eine POST-Anfrage nach einem 301 in GET ändern.
401 oder 403
Eine API gibt 401 zurück, wenn kein Token oder ein abgelaufenes Token gesendet wird. Der Client sollte sich dann anmelden. 403 wird zurückgegeben, wenn das Token gültig ist, der Benutzer aber keine Berechtigung hat. Eine erneute Anmeldung hilft dann nicht.
Einen 502-Fehler hinter nginx diagnostizieren
Ein 502 Bad Gateway von nginx bedeutet, dass die dahinterliegende Anwendung nicht ordnungsgemäß geantwortet hat. Prüfen Sie, ob der Anwendungsprozess läuft und welche Meldungen er protokolliert hat. 504 bedeutet dagegen, dass die Antwort zu lange gedauert hat.
Häufig gestellte Fragen
Was ist der Unterschied zwischen 404 und 410?
404 bedeutet, dass der Server die Ressource nicht finden kann, und sagt nichts über ihre Zukunft aus. 410 bedeutet, dass die Ressource absichtlich entfernt wurde und nicht zurückkehren wird. So können Suchmaschinen die URL schneller aus dem Index entfernen.
Sollte ein Validierungsfehler 400 oder 422 zurückgeben?
Beide Codes werden verwendet. 400 passt zu Anfragen, die der Server nicht parsen kann, etwa fehlerhaftes JSON. 422 passt zu Anfragen, die sich korrekt parsen lassen, aber ungültige Werte enthalten, zum Beispiel eine E-Mail-Adresse ohne @.
Ist 418 I'm a teapot ein echter Statuscode?
Der Code stammt aus einem Aprilscherz-RFC von 1998. RFC 9110 reserviert 418 als ungenutzt, damit der Code nicht anderweitig vergeben wird. Einige Server geben ihn als Scherz zurück, eine standardisierte Bedeutung hat er aber nicht.
Woher kommt 499?
499 ist nginx-spezifisch. Der Code erscheint in nginx-Protokollen, wenn der Client die Verbindung schließt, bevor der Server eine Antwort sendet. Der Client erhält nie den Status 499; er weist meist auf langsame Antworten oder clientseitige Timeouts hin.
Behandeln Suchmaschinen 302 wie 301?
302 signalisiert eine vorübergehende Weiterleitung. Daher behalten Suchmaschinen zunächst meist die ursprüngliche URL im Index. Bleibt eine 302-Weiterleitung lange bestehen, kann Google sie wie eine permanente Weiterleitung behandeln. Verwenden Sie für permanente Weiterleitungen 301 oder 308.
Datenschutz
Die Liste ist Teil der Seite. Suche und Filterung erfolgen in Ihrem Browser; Ihre Suchbegriffe werden weder übertragen noch in Analysen erfasst.