Skip to main content

HTTP-Statuscodes Referenz

Durchsuchbare Referenz aller HTTP-Statuscodes mit Beschreibungen.

Geprüft von · Zuletzt geprüft

61 codes found

So wird die HTTP-Statuscode-Referenz verwendet

  1. In das Suchfeld tippen, um die Liste zu filtern. Der Filter gleicht Codenummern ("404"), Statusnamen ("Not Found") oder Phrasen in der Beschreibung ("rate limit") ab.
  2. Die Kategorie-Schaltflächen verwenden (1xx, 2xx, 3xx, 4xx, 5xx), um die Tabelle auf eine einzelne Antwortklasse einzuschränken.
  3. Auf eine Zeile klicken, um sie zu erweitern und den RFC-Verweis, häufige Ursachen und reale Szenarien zu sehen, in denen der Code zurückgegeben wird.
  4. Einen Code oder Ausdruck kopieren mit der integrierten Kopierschaltfläche, wenn ein Beispiel in eine API-Spezifikation, Postman oder ein Bug-Ticket eingefügt werden soll.
  5. Seite als Lesezeichen speichern für eine schnelle Offline-Referenz - sie funktioniert ohne Netzwerkverbindung, sobald sie geladen wurde.

Wie die Referenz aufgebaut wurde

Die Codeliste wurde aus RFC 9110 (HTTP Semantics, die 2022er Konsolidierung des HTTP/1.1-Verhaltens) zusammengestellt, plus eine Handvoll noch relevanter Vorgänger: RFC 7231 für die klassische Statuscode-Registry, RFC 7232 für bedingte Anfragen (304), RFC 7538 (308 Permanent Redirect), RFC 6585 (428, 429, 431, 511) und die WebDAV-Erweiterungen in RFC 4918 (102, 207, 422, 423, 424, 507, 508). Die Daten liegen als statisches JSON-Array vor, das mit der Seite ausgeliefert wird - jede Suche und Filterung ist reine In-Browser-JavaScript-Array-Verarbeitung, sodass die Eingabe im Filterfeld in Mikrosekunden zurückgegeben wird. Kein Netzwerk-Round-Trip, keine Serverkomponente, kein Analytics-Event bei jedem Tastendruck. Die Benutzeroberfläche verwendet String.prototype.includes auf normalisierten klein geschriebenen Suchbegriffen, um lokalübergreifende Konsistenz zu gewährleisten.

Wann dieses Tool benötigt wird

  • Beim Schreiben einer API und der Entscheidung zwischen 409 Conflict und 422 Unprocessable Content für einen Duplikat-Ressourcenfehler.
  • Beim Debuggen eines Produktionsvorfalls, bei dem das Gateway 503 zurückgibt, und der Bestätigung, ob Clients es erneut versuchen sollten.
  • Beim Dokumentieren einer OpenAPI-Spezifikation und dem Einfügen der kanonischen Statusphrase in die response.description-Felder.
  • Beim Erklären gegenüber einem nicht-technischen Stakeholder, warum eine 302-Weiterleitung im Vergleich zu einer 301 SEO-Wert verliert.
  • Beim Konfigurieren einer Wiederholungsrichtlinie in einer HTTP-Client-Bibliothek - 5xx-Codes sind sicher wiederholbar, 4xx-Codes meistens nicht.
  • Beim Erklären eines Junior-Entwicklers den Unterschied zwischen 401 ("Wir wissen nicht, wer Sie sind") und 403 ("Wir wissen es und die Antwort ist nein").

Häufige Fallstricke und Randfälle

  • 418 I'm a Teapot. Definiert im Aprilscherz-RFC 2324 von 1998 und aus den echten HTTP-Standards ausgeschlossen. Charmant, aber nicht normativ; Produktionssysteme sollten ihn nicht ernsthaft zurückgeben.
  • 200 OK für Fehler verwenden. Manche APIs geben HTTP 200 mit {"error": ...} im Body zurück, um das Abrufen zu vereinfachen. Das bricht Wiederholungslogik, Caching und Monitoring-Dashboards, die auf Statuscodes basieren. Den richtigen Status zurückgeben.
  • 301 vs. 308. Beide sind permanente Weiterleitungen, aber 301 erlaubte Clients historisch, POST zu GET zu ändern; 308 erhält die Methode explizit. 308 verwenden, wenn der Body und das Verb am Weiterleitungsziel behalten werden müssen.
  • 429 ohne Retry-After. RFC 6585 verlangt, dass Server, die 429 Too Many Requests zurückgeben, einen Retry-After-Header einschließen, damit Clients ein vernünftiges Backoff implementieren können. Das Weglassen zwingt Clients zum Raten, was normalerweise bedeutet, den Rate-Limiter zu hammern.
  • 204 vs. 200 mit leerem Body. 204 No Content signalisiert Erfolg ohne Body; es ist semantisch sauberer für DELETE-Antworten und für PATCH, das die geänderte Ressource nicht zurückgibt. 200 mit leerem Body ist legal, aber unklarer.
  • 3xx-Codes sind keine Fehler. Monitoring-Dashboards, die auf "non-2xx" alarmieren, werden bei völlig normalen 304 Not Modified-Antworten vom CDN ausgelöst. 3xx aus den Fehlerrate-SLO-Berechnungen ausschließen.

HTTP-Statuscode-Klassen

Die erste Ziffer des dreistelligen Codes klassifiziert die Antwort. 1xx-Codes sind informativ (100 Continue, 101 Switching Protocols, 103 Early Hints für Preload-Hinweise) und bleiben normalerweise unsichtbar, weil die Antwort transient ist. 2xx-Codes bedeuten, dass die Anfrage erfolgreich war: 200 für "Hier ist dein Inhalt", 201 für "erstellt", 202 für "asynchron akzeptiert", 204 für "erfolgreich, nichts zurückzugeben", 206 für "Teilinhalt, wie mit Range angefragt". 3xx signalisiert Weiterleitung: 301 und 308 permanent, 302 und 307 temporär, 304 Not Modified für bedingte Anfragen. 4xx zeigt ein clientseitiges Problem an, das der Client beheben kann: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 410 Gone, 422 Unprocessable Content, 429 Too Many Requests. 5xx signalisiert ein serverseitiges Problem, das der Client nicht beheben kann: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout. RFC 9110 behandelt unbekannte Codes als unbekannt mit derselben Klasse - ein exotischer 499 von Nginx wird also immer noch als Client-Fehler geparst.

Vergleich mit Alternativen

httpstatuses.com und httpstatus.com sind bekannte durchsuchbare Referenzen mit ausführlicheren Beschreibungen. Mozillas MDN Web Docs hat pro Code eine Statuscode-Seite mit Browser-Kompatibilitätsdaten und Querverweisen auf verwandte Header - die beste Tiefenrecherche-Ressource, wenn subtiles Verhalten verstanden werden muss. Im Terminal gibt curl -I den Code aus einer echten Anfrage zurück, und man 7 http_status_codes (auf manchen Distributionen) liefert eine schnelle Übersicht. Postman und Insomnia zeigen Statuscodes inline mit farbigen Abzeichen. Diese Seite ist nützlich für filtergesteuertes Offline-Browsen, besonders wenn man sich an eine Phrase ("unprocessable") erinnert, aber nicht an die Nummer.

Häufig gestellte Fragen

Was ist die maßgebliche Quelle für HTTP-Statuscodes?

RFC 9110 (HTTP Semantics) ist die aktuelle Spezifikation und ersetzt RFC 7230 bis RFC 7235. Das IANA HTTP Status Code Registry verfolgt alle Zuweisungen. Die Daten dieses Tools werden aus diesen Quellen zusammengestellt.

Was ist der praktische Unterschied zwischen 401 und 403?

401 Unauthorized bedeutet, dass die Authentifizierung fehlt oder fehlgeschlagen ist - erneut anmelden. 403 Forbidden bedeutet, dass die Authentifizierung erfolgreich war, aber die Berechtigung für diese Ressource fehlt - eine erneute Authentifizierung hilft nicht. Eine sauber gestaltete API verwendet 401 für ungültige Token und 403 für unzureichende Berechtigungen.

Wann sollte ich 404 gegenüber 410 verwenden?

404 Not Found bedeutet, dass die Ressource unter dieser URL nicht existiert - entweder hat sie nie existiert oder der Server verfolgt ihre frühere Existenz nicht. 410 Gone bedeutet, dass die Ressource früher unter dieser URL existiert hat und absichtlich entfernt wurde, ohne Weiterleitungsadresse. 410 verwenden, wenn ein Endpunkt dauerhaft abgeschaltet wird, damit Suchmaschinen ihn schneller aus dem Index entfernen und Clients aufhören, es erneut zu versuchen. 404 für alles andere verwenden.

Führt dieses Tool API-Aufrufe durch, um Codes nachzuschlagen?

Nein. Die gesamte Statuscode-Liste wird zur Build-Zeit als JavaScript-Array in die Seite eingebettet. Filtern und Suchen läuft als einfache Array.filter- und String.includes-Aufrufe im Browser ab, ohne Netzwerkverkehr. Das bedeutet auch, dass das Tool nach dem ersten Laden offline funktioniert - praktisch im Flugzeug, in der U-Bahn oder hinter strengen Unternehmensfirewalls.

Was hat es mit dem Statuscode 418 I am a teapot auf sich?

Er wurde in RFC 2324 definiert, dem Hyper Text Coffee Pot Control Protocol - ein Aprilscherz von 1998, der von Kaffeemaschinen zurückgegeben werden sollte, wenn sie zum Teebrühen aufgefordert werden. Er war nie Teil des echten HTTP-Standards, ist aber berühmt als Easter Egg in mehreren Servern und Bibliotheken implementiert. Die IANA führt ihn nicht im offiziellen Registry. Ihn in Produktions-APIs nicht zurückgeben - Clients und Middleware könnten ihn unvorhersehbar behandeln.

Wie soll mit 429 Too Many Requests umgegangen werden?

Den Retry-After-Header lesen und mindestens so lange warten. Falls fehlend, exponentielles Backoff mit Jitter anwenden - 1 Sekunde Basis, Verdopplung bei jedem Versuch bis zu einem Maximum, plus Zufälligkeit zur Vermeidung synchronisierter Wiederholungen. Bibliotheken wie axios-retry, node-fetch-retry und Pythons tenacity verwalten das. Schnelle Wiederholungen ohne Backoff verschlimmern Rate-Limits für alle.

Warum wurde 308 Permanent Redirect so spät hinzugefügt?

Weil 301 eine Eigenheit hatte: Clients durften beim Folgen der Weiterleitung POST zu GET ändern, und viele alte Clients taten das. 308 wurde in RFC 7538 (2015) spezifiziert, um die Methodenerhaltung voranzuschreiben. 308 verwenden, wenn das Weiterleitungsziel den ursprünglichen Body und das Verb benötigt; 301 ist sicher für einfache GETs.

Welche Statuscodes signalisieren, dass ein erneuter Versuch sicher ist?

Alle 5xx-Codes außer 501 Not Implemented sind sicher wiederholbar, da sie vorübergehende serverseitige Probleme anzeigen. 408 Request Timeout und 429 Too Many Requests sind aus der 4xx-Familie ebenfalls wiederholbar. 425 Too Early signalisiert, dass der Server eine 0-RTT- Anfrage nicht verarbeiten wird, und legt nahe, mit einer stärkeren Verbindung erneut zu versuchen. Andere 4xx-Codes (400, 401, 403, 404, 409, 410, 422) sind nicht wiederholbar, ohne die Anfrage vorher zu korrigieren.

Gibt es einen Code für "Ich habe das noch nicht implementiert"?

Ja, 501 Not Implemented ist speziell für diesen Fall gedacht - der Server erkennt die Anfragemethode nicht oder kann sie nicht erfüllen. Für einen API-Endpunkt, der zwar existiert, aber deaktiviert ist, ist 403 Forbidden oder 410 Gone normalerweise besser. 501 ist bei modernen APIs selten zu sehen, da Frameworks 404 oder 405 Method Not Allowed zurückgeben, bevor die Anfrage den Anwendungscode erreicht.

Wie funktioniert 304 Not Modified?

Wenn ein Client eine bedingte Anfrage mit If-Modified-Since- oder If-None-Match-Headern sendet, prüft der Server, ob sich die Ressource seit diesem Zeitstempel geändert hat oder zu diesem ETag passt. Falls nicht, gibt er 304 ohne Body zurück und signalisiert damit, dass die gecachte Kopie des Clients noch gültig ist. Die Antwort enthält Header (Cache-Control, Expires, ETag), aber null Body-Bytes, was sie extrem günstig zu bedienen macht. Das CDN vor einem Origin ist stark auf 304 für Effizienz angewiesen.

Kann ein Server einen Statuscode zurückgeben, der in keinem RFC definiert ist?

Ja. Nginxs 499 Client Closed Request ist in keinem RFC enthalten, taucht aber häufig in Zugriffsprotokollen auf. Cloudflare gibt 520-527 für edge-spezifische Fehler zurück. RFC 9110 besagt, dass unbekannte Codes als x00 derselben Klasse behandelt werden sollten. Für öffentliche APIs bei registrierten Codes bleiben.

Verwandte Tools

Mehr Developer Tools

AI Token Counter

Count tokens for GPT-4o, Claude, and Gemini models instantly.

Open tool

Base64 Encoder & Decoder

Encode UTF-8 text to Base64 online or decode Base64 back to UTF-8 and plain text. Runs in your browser with no upload.

Open tool

Bulk URL Encode / Decode

Encode or decode many URLs at once. Paste a newline-separated list and the tool processes each line in parallel, preserving order and blank lines.

Open tool

chmod Calculator

Calculate and convert Unix file permission modes between octal and symbolic.

Open tool

Code Screenshot

Create beautiful code snippet images with customizable themes.

Open tool

Color Converter

Convert colors between HEX, RGB, HSL and CMYK formats.

Open tool
ZeroUtil unterstützen