Guide
Die HTTP-Statuscode-Übersicht versammelt 72 Codes: alle Standardcodes aus RFC 9110 (100–101, 200–206, 300–308, 400–418, 421, 422, 426, 500–505), die Erweiterungscodes aus RFC 6585 / 7725 / 8297 / 8470 sowie der WebDAV-Reihe (103, 207, 208, 226, 423–425, 428, 429, 431, 451, 506–511) und schließlich die nicht standardisierten Codes, die in keinem RFC stehen, bei der Fehlersuche im Livebetrieb aber täglich auftauchen – 444 und 499 von nginx, 520–526 von Cloudflare.
Aktualisiert am 2026-09-094 sources8 min read
Die HTTP-Statuscode-Übersicht versammelt 72 Codes: alle Standardcodes aus RFC 9110 (100–101, 200–206, 300–308, 400–418, 421, 422, 426, 500–505), die Erweiterungscodes aus RFC 6585 / 7725 / 8297 / 8470 sowie der WebDAV-Reihe (103, 207, 208, 226, 423–425, 428, 429, 431, 451, 506–511) und schließlich die nicht standardisierten Codes, die in keinem RFC stehen, bei der Fehlersuche im Livebetrieb aber täglich auftauchen – 444 und 499 von nginx, 520–526 von Cloudflare.
Anders als Tabellen, die nur die „Bedeutung“ nennen, ist hier jeder Code in vier Abschnitte gegliedert: seine Semantik; wann er dir begegnet; was Frontend / Client damit tun sollte (erneut versuchen? zum Login springen? welchen Response-Header lesen?); und wann das Backend ihn zurückgeben sollte und welche Header mitgehören. Häufige Codes erhalten zusätzlich einen Absatz „Typische Fehlverwendung“, denn die meisten Statuscode-Probleme entstehen nicht aus Unkenntnis, sondern durch falsche Verwendung – 200 bei fachlichem Fehlschlag, 403 für abgemeldete Nutzer, 503 beim Rate Limiting.
Oben auf der Seite stehen außerdem sieben Gruppen „leicht verwechselbarer“ Codes: 401 vs. 403, 301/302/307/308, 400 vs. 422, 404 vs. 410, 502/503/504, 200/201/202/204 und 429 vs. 503. Genau diese Kombinationen werden in Interviews, Code-Reviews und bei der Fehlersuche am häufigsten gefragt.
502) – die exakt passende Karte erscheint ganz oben.Nach „429“ suchen – so sieht die Karte aus (Auszug):
Die zugehörige Backend-Antwort sieht so aus:
429 Too Many Requests Zu viele Anfragen RFC 6585
Bedeutung In einem bestimmten Zeitraum wurden zu viele Anfragen gesendet (Rate Limiting).
Wann API-Frequenzgrenzen, zu viele Login-Versuche, ein gedrosselter Crawler, eine KI-API über ihrem Minutenkontingent.
Client Nach dem Lesen von Retry-After (Sekunden oder Datum) mit exponentiellem Backoff erneut versuchen; dem Nutzer „später erneut versuchen“ anzeigen; nicht sofort wiederholen.
Server Retry-After- und RateLimit-*-Header mitsenden; pro Nutzer / IP / API-Key zählen.
Fehlverwendung Rate Limiting liefert 403 oder 503, der Client kann nicht unterscheiden, ob es an Rechten liegt oder am Warten.HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30
RateLimit-Limit: 60
RateLimit-Remaining: 0
RateLimit-Reset: 30
{"error":"rate_limited","message":"maximal 60 Anfragen pro Minute, bitte in 30 Sekunden erneut versuchen"}Die erste Ziffer entscheidet über die Klasse, und das ist Absicht: Auch wenn ein Client einen konkreten Code nicht kennt (etwa das neue 425), behandelt er ihn über die Klasse richtig – jedes 4xx heißt „nicht unverändert wiederholen, das Problem liegt in der Anfrage“, jedes 5xx „später erneut versuchen“, jedes 3xx „Location ansehen“. RFC 9110 verlangt ausdrücklich, dass Clients die Klassensemantik verstehen, einzelne Codes aber nicht kennen müssen. Deshalb gehört auch ein selbst definierter Statuscode in den richtigen Hunderterbereich.
Ein historischer Benennungsfehler. Frühes HTTP unterschied authentication (wer du bist) nicht von authorization (was du darfst); 401 bekam den Namen Unauthorized, doch der begleitende WWW-Authenticate-Header und die Semantik „nach erneuter Angabe von Zugangsdaten kann es klappen“ sprechen beide von Authentifizierung. RFC 9110 formuliert in §15.5.2 inzwischen "lacks valid authentication credentials". Ein Satz zum Merken: 401 = bitte anmelden, 403 = angemeldet reicht auch nicht. Das Frontend entscheidet danach, ob es zur Login-Seite springt oder „keine Berechtigung“ zeigt; falsch herum eingesetzt landen angemeldete Nutzer immer wieder auf der Login-Seite.
Die vier gängigen Redirect-Codes sind eine 2×2-Matrix. 301 und 308 sind dauerhaft (Browser und Suchmaschinen merken sich die neue Adresse), 302 und 307 sind temporär. Historisch machten Browser aus einem POST bei 301/302 ein GET; RFC 9110 erkennt diese Realität an und bietet mit 307/308 die strikten Varianten, bei denen „Methode und Request-Body erhalten bleiben müssen“. Für einen https-Redirect einer Website ist 301 in Ordnung; bei der Migration eines API-Endpunkts muss ein POST 307/308 verwenden, sonst geht der Request-Body verloren.
304 wird oft für „eine Anfrage gespart“ gehalten. Tatsächlich hat der Browser trotzdem eine bedingte Anfrage mit If-None-Match / If-Modified-Since geschickt, der Server hat verglichen und mit 304 ohne Response-Body geantwortet – gespart wird die Übertragung, nicht der Roundtrip. Anfragen wirklich sparen lässt sich mit Cache-Control: max-age (innerhalb der Gültigkeit fragt der Browser den Server gar nicht); beide greifen zusammen: während max-age läuft, direkt verwenden, nach Ablauf per bedingter Anfrage mit 304 verlängern. In den DevTools ist "200 (from disk cache)" das Erste und "304" das Zweite.
Die häufigste 5xx-Familie im Livebetrieb; sie auseinanderzuhalten grenzt die Fehlersuche sofort ein. Ein Reverse Proxy (Nginx, Gateway, CDN) erreicht das Upstream nicht oder das Upstream lieferte etwas Ungültiges – 502, also nachsehen, ob der Anwendungsprozess abgestürzt ist; das Upstream sagt ausdrücklich, dass es ausgelastet ist oder gewartet wird – 503, meist bewusst zurückgegeben, also Healthchecks und Circuit Breaker ansehen; das Upstream antwortet nicht – 504, also Slow Queries und Timeout-Konfiguration prüfen. Cloudflare teilt diese drei Fälle in 520–526 auf, wobei 521 ≈ 502 (Verbindung abgelehnt), 522/524 ≈ 504 (Verbindungs- / Lesetimeout) und 525/526 Probleme auf TLS-Ebene sind.
Das häufigste Anti-Muster: alle Anfragen mit 200 beantworten und den Fehler in ein code-Feld des Response-Bodys legen. Das lässt CDNs Fehlerseiten cachen, macht 5xx-Alarme im Monitoring wirkungslos, entwertet das fetch().ok des Browsers und lässt Retry-Strategien ohne Anhaltspunkt. Richtig ist die Aufteilung: Der HTTP-Statuscode sagt, was auf Anfrageebene passiert ist (Semantik nach RFC 9110), der Business-Code im Body beschreibt das fachliche Detail – die beiden teilen sich die Arbeit, statt einander zu ersetzen: Zu wenig Bestand ist 422 + {"code":"OUT_OF_STOCK"}, nicht 200 + {"code":500}.
Die Vergleichstabelle 502 / 503 / 504 sagt, ob die Anwendung abgestürzt ist, aus dem Verkehr genommen wurde oder zu langsam ist; die Cloudflare-52x-Karten weisen direkt auf „Firewall / Zertifikat / Timeout des Origins prüfen“.
Den Interceptor anhand der Spalte „Frontend / Client“ schreiben: 401 erneuert das Token oder springt zum Login, 403 zeigt „keine Berechtigung“, 429 liest Retry-After und geht in den Backoff, 5xx versucht begrenzt erneut und meldet.
Liefert das Anlegen einer Ressource 201 + Location? Liefert das Löschen 204? Ist eine fehlgeschlagene Business-Validierung eine 400 oder eine 422? Trägt das Rate Limiting Retry-After? Die Spalten „Server“ und „Fehlverwendung“ sind die Prüfliste.
Die sieben Vergleichsgruppen decken die häufigsten „Was ist der Unterschied“-Fragen ab; „Funktionsweise“ erklärt die Benennung von 401, die Herkunft von 307/308 und die tatsächliche Wirkung von 304.
Der Einstiegsserver der Website (das Gateway) erreicht das Backend nicht, das die Anfrage eigentlich bearbeitet – meist ist der Backend-Prozess abgestürzt oder startet gerade neu. Als Nutzer kann man nur später aktualisieren; gehört die Seite dir, schau nach dem Backend-Prozess und den Fehlerlogs des Gateways.
Client: den Retry-After-Header lesen, die angegebene Zeit abwarten und dann erneut versuchen, bei wiederholten Fehlschlägen exponentiell zurückfahren (1 s, 2 s, 4 s…) und dem Nutzer „zu viele Versuche“ anzeigen. Server: bei einer 429 immer Retry-After mitsenden, idealerweise zusätzlich RateLimit-*-Header, damit Clients frühzeitig langsamer werden.
Das hängt vom angefragten Objekt ab. GET /users/123, und 123 existiert nicht – 404; GET /users?name=xxx mit leerem Ergebnis – 200 + leeres Array. Ein leeres Ergebnis eines Listen-Endpunkts ist ein legitimes „es gibt ein Ergebnis, und es ist leer“, kein Fehler.
Eine 204 hat keinen Response-Body, und json() wirft beim Parsen eines leeren Strings einen SyntaxError. Erst response.status === 204 prüfen (oder response.headers.get('content-length') === '0') und dann entscheiden, ob geparst wird.
Das sind interne Codes, die nginx ins Access-Log schreibt: 444 bedeutet, nginx hat die Verbindung ohne jede Antwort geschlossen, 499 bedeutet, der Client hat getrennt, bevor nginx geantwortet hat. Im Browser sieht man „Verbindung zurückgesetzt“ oder gar keine Antwort.
Die Statuscode-Daten kommen statisch mit der Seite; Suchen, Filtern, Kopieren und Merken laufen lokal im Browser und senden keine Anfragen. Favoriten liegen im localStorage des Browsers. Die externen Links führen zum RFC Editor, zu IANA und zur Cloudflare-Dokumentation und werden beim Klick von der jeweiligen Gegenseite verarbeitet.
Aktualisiert am 2026-09-09
Alle Statuscodes aus RFC 9110 plus Erweiterungen und die nicht standardisierten von nginx und Cloudflare, insgesamt 72: jeweils Bedeutung, Auftreten, Behandlung in Frontend und Backend sowie typische Fehlverwendung, dazu sieben Gruppen leicht verwechselbarer Codes; durchsuchbar, kopierbar, als Favorit speicherbar
Dieses Werkzeug ist noch nicht vollständig übersetzt; einige Inhalte nutzen die Ausgangssprache oder die Rückfallsprache.
Die Anfrage ist eingegangen und wird weiter verarbeitet; Browser zeigen das Seiten-Skripten fast nie.
Die Anfrage-Header sind eingegangen; der Client darf den Anfrage-Body weiter senden.
RFC 9110 §15.2.1
Der Server stimmt dem Protokollwechsel über den Upgrade-Header zu.
RFC 9110 §15.2.2
Der Server hat die Anfrage erhalten und verarbeitet sie, aber es gibt noch keine endgültige Antwort.
RFC 2518 (WebDAV, veraltet)
Vor der endgültigen Antwort werden einige Header gesendet – vor allem Link: preload –, damit der Browser Ressourcen früher lädt.
RFC 8297
Die Anfrage wurde erfolgreich empfangen, verstanden und verarbeitet.
Die Anfrage war erfolgreich; der Body enthält die angeforderte Ressource oder das Ergebnis der Operation.
RFC 9110 §15.3.1
Die Anfrage war erfolgreich und es wurde eine neue Ressource angelegt.
RFC 9110 §15.3.2
Die Anfrage wurde angenommen, aber noch nicht verarbeitet – die Quittung für eine asynchrone Aufgabe.
RFC 9110 §15.3.3
Die Antwort ist erfolgreich, aber ihr Inhalt wurde von einem zwischengeschalteten Proxy verändert.
RFC 9110 §15.3.4
Erfolgreich, aber ohne Antwort-Body.
RFC 9110 §15.3.5
Erfolgreich, und der Client soll die Dokumentansicht zurücksetzen (etwa ein Formular leeren).
RFC 9110 §15.3.6
Es wird nur ein Teil der Ressource zurückgegeben (erfolgreiche Range-Anfrage).
RFC 9110 §15.3.7
Der Body ist XML, und jede Unterressource meldet ihren eigenen Status.
RFC 4918 (WebDAV)
Innerhalb einer 207-Antwort wurde dieselbe Ressource bereits gemeldet und wird nicht wiederholt.
RFC 5842 (WebDAV)
Der Server hat Instanz-Manipulationen (Delta-Encoding) auf die aktuelle Instanz angewendet und die Differenz zurückgegeben.
RFC 3229
Der Client muss weitere Schritte ausführen – meist eine andere Adresse anfragen –, bevor die Anfrage abgeschlossen ist.
Die Ressource hat mehrere Repräsentationen; der Client soll eine wählen.
RFC 9110 §15.4.1
Die Ressource ist dauerhaft unter der neuen URL in Location zu finden; ab jetzt diese URL verwenden.
RFC 9110 §15.4.2
Die Ressource ist vorübergehend woanders; nächstes Mal weiter die ursprüngliche URL anfragen.
RFC 9110 §15.4.3
Das Ergebnis mit GET von Location holen, unabhängig von der Methode dieser Anfrage.
RFC 9110 §15.4.4
Die Ressource hat sich nicht geändert – die Kopie aus dem Cache verwenden.
RFC 9110 §15.4.5
Auf die Ressource darf nur über den in Location genannten Proxy zugegriffen werden.
RFC 9110 §15.4.6 (veraltet)
Sollte in einem Entwurf den Proxy-Wechsel ausdrücken; der Code ist reserviert und ungenutzt.
RFC 9110 §15.4.7
Eine temporäre Weiterleitung, bei der der Client dieselbe Methode und denselben Body erneut senden muss.
RFC 9110 §15.4.8
Eine dauerhafte Weiterleitung, die Methode und Body beibehält (die strikte Variante von 301).
RFC 9110 §15.4.9
Die Anfrage selbst ist fehlerhaft: Syntax, Authentifizierung, fehlende Ressource, zu hohe Frequenz … ein erneuter identischer Versuch wird nicht gelingen.
Der Server kann die Anfrage nicht verstehen: falsche Syntax, fehlende oder fehlerhafte Parameter oder nicht parsierbares JSON.
RFC 9110 §15.5.1
Zugangsdaten fehlen oder sind ungültig – "Wer bist du?" (der Name Unauthorized bedeutet tatsächlich nicht authentifiziert).
RFC 9110 §15.5.2
Für künftige digitale Zahlungen reserviert; die Spezifikation definiert keine konkrete Semantik.
RFC 9110 §15.5.3 (reserviert)
Der Server weiß, wer du bist, aber dir fehlt die Berechtigung – "du darfst nicht". Erneutes Anmelden hilft nicht.
RFC 9110 §15.5.4
Der Server findet die angeforderte Ressource nicht und sagt nicht, ob das vorübergehend oder dauerhaft ist.
RFC 9110 §15.5.5
Die Ressource existiert, unterstützt diese HTTP-Methode aber nicht.
RFC 9110 §15.5.6
Der Server hat keine Repräsentation, die Accept / Accept-Language erfüllt.
RFC 9110 §15.5.7
Zuerst muss man sich beim Proxy-Server authentifizieren (die Proxy-Variante von 401).
RFC 9110 §15.5.8
Der Server hat zu lange auf die Anfrage gewartet (der Client hat sie nicht zu Ende gesendet).
RFC 9110 §15.5.9
Die Anfrage steht im Konflikt mit dem aktuellen Zustand der Ressource; der Nutzer kann ihn durch Ändern der Anfrage lösen.
RFC 9110 §15.5.10
Die Ressource existierte einmal und ist jetzt dauerhaft entfernt, ohne Weiterleitungsadresse.
RFC 9110 §15.5.11
Der Server verlangt Content-Length in der Anfrage.
RFC 9110 §15.5.12
Eine Bedingung in den Anfrage-Headern (If-Match, If-Unmodified-Since) ist nicht erfüllt.
RFC 9110 §15.5.13
Der Anfrage-Body überschreitet die vom Server erlaubte Größe.
RFC 9110 §15.5.14 (früher Payload Too Large)
Die URL ist zu lang, als dass der Server sie verarbeiten könnte.
RFC 9110 §15.5.15
Der Server unterstützt das Format (Content-Type) des Anfrage-Bodys nicht.
RFC 9110 §15.5.16
Der im Range-Header angeforderte Byte-Bereich liegt außerhalb der Ressourcengröße.
RFC 9110 §15.5.17
Der Server kann den Expect-Header nicht erfüllen.
RFC 9110 §15.5.18
Ein Scherz aus einem Aprilscherz-RFC von 1998; im echten HTTP nicht verwenden.
RFC 2324 (Aprilscherz-RFC); von RFC 9110 als ungenutzt markiert
Die Anfrage erreichte einen Server, der für diese Authority (Domain) keine Antwort liefern kann.
RFC 9110 §15.5.20
Syntax und Format sind in Ordnung, aber die Anfrage ist semantisch nicht verarbeitbar (fachliche Validierung fehlgeschlagen).
RFC 9110 §15.5.21 (früher Unprocessable Entity)
Die Ressource ist gesperrt.
RFC 4918 (WebDAV)
Diese Operation ist fehlgeschlagen, weil zuvor eine abhängige Operation fehlgeschlagen ist.
RFC 4918 (WebDAV)
Der Server will eine möglicherweise wiederholbare Anfrage nicht verarbeiten (TLS 1.3 0-RTT Early Data).
RFC 8470
Der Server lehnt die Verarbeitung im aktuellen Protokoll ab und verlangt den Wechsel zum im Upgrade-Header genannten Protokoll.
RFC 9110 §15.5.22
Der Server verlangt einen Conditional-Header (etwa If-Match), um verlorene Updates zu verhindern.
RFC 6585
In einem bestimmten Zeitfenster wurden zu viele Anfragen gesendet (Rate Limiting).
RFC 6585
Ein Anfrage-Header (ein Feld oder die Summe) ist zu groß.
RFC 6585
Die Ressource wird aus rechtlichen Gründen vorenthalten (Urheberrecht, behördliche Anordnungen). Die Nummer verweist auf den Roman Fahrenheit 451.
RFC 7725
Der Server weiß, dass er fehlgeschlagen ist oder eine gültige Anfrage nicht erfüllen kann; ein späterer Versuch kann gelingen.
Der Server ist auf eine unerwartete Bedingung gestoßen und konnte die Anfrage nicht abschließen.
RFC 9110 §15.6.1
Der Server unterstützt die für die Anfrage nötige Funktionalität nicht (meist eine unbekannte Methode).
RFC 9110 §15.6.2
Ein als Gateway oder Proxy agierender Server erhielt eine ungültige Antwort von seinem Upstream.
RFC 9110 §15.6.3
Der Server kann die Anfrage vorübergehend nicht bearbeiten (überlastet oder in Wartung), meist nur für eine Weile.
RFC 9110 §15.6.4
Das Gateway/der Proxy hat beim Warten auf eine Upstream-Antwort das Timeout erreicht.
RFC 9110 §15.6.5
Der Server unterstützt die von der Anfrage genutzte HTTP-Hauptversion nicht.
RFC 9110 §15.6.6
Eine Fehlkonfiguration der Inhaltsaushandlung erzeugt eine Schleife.
RFC 2295
Der Server kann den für die Anfrage nötigen Inhalt nicht speichern.
RFC 4918 (WebDAV)
Bei der Verarbeitung der Anfrage wurde eine Endlosschleife erkannt.
RFC 5842 (WebDAV)
Die Anfrage muss erst weiter erweitert werden, bevor der Server sie verarbeiten kann.
RFC 2774 (historisch)
Der Client muss sich auf Netzwerkebene authentifizieren (Captive Portal), bevor er online gehen kann.
RFC 6585
Diese Codes stehen in keiner RFC und tauchen nur in Logs bestimmter Server oder auf CDN-Fehlerseiten auf; kennt man sie, spart das viel Fehlersuche.
nginx schließt die Verbindung ohne jede Antwort; nur in nginx-Logs sichtbar.
nginx-spezifisch
Der Client hat getrennt, bevor der Server antwortete; nur in nginx-Logs sichtbar.
nginx-spezifisch
Die Antwort des Ursprungs an Cloudflare war leer, fehlerhaft oder die Header waren zu groß.
Cloudflare-spezifisch
Cloudflare erreicht den Ursprung nicht (die TCP-Verbindung wird abgelehnt).
Cloudflare-spezifisch
Die TCP-Verbindung von Cloudflare zum Ursprung lief in ein Timeout.
Cloudflare-spezifisch
Cloudflare kann nicht zum Ursprung routen (DNS- oder Netzwerk-Routing-Problem).
Cloudflare-spezifisch
TCP war verbunden, aber der Ursprung lieferte innerhalb von 100 Sekunden keine HTTP-Antwort.
Cloudflare-spezifisch
Der TLS-Handshake zwischen Cloudflare und dem Ursprung ist fehlgeschlagen.
Cloudflare-spezifisch
Im Modus Full (strict) ist das Ursprungszertifikat abgelaufen, selbstsigniert oder passt nicht zur Domain.
Cloudflare-spezifisch