HTTP-Statuscode-Abfrage
Schnellreferenz für HTTP-Statuscodes mit Beschreibungen
1xx Information(4)
Fortsetzen. Client sollte den Rest der Anfrage senden.
Protokollwechsel. Server versteht und wechselt Protokoll.
Verarbeitung. Server hat Anfrage erhalten und verarbeitet.
Frühe Hinweise. Gibt Header vor der finalen Antwort zurück.
2xx Erfolg(10)
Erfolg. Anfrage erfolgreich verarbeitet.
Erstellt. Neue Ressource erstellt. Häufig bei POST.
Akzeptiert. Anfrage angenommen, aber noch nicht abgeschlossen.
Nicht-autorisierende Information. Info könnte von Dritten stammen.
Kein Inhalt. Erfolg ohne Antwortkörper. Häufig bei DELETE.
Inhalt zurücksetzen. Dokumentenansicht zurücksetzen.
Teilinhalt. Partieller GET erfolgreich.
Multi-Status. Mehrere Statuscodes in Antwort (WebDAV).
Bereits gemeldet. DAV-Bindungen bereits aufgeführt (WebDAV).
IM verwendet. GET mit Instanzmanipulation abgeschlossen.
3xx Weiterleitung(8)
Mehrere Auswahlmöglichkeiten. Verschiedene Darstellungen verfügbar.
Dauerhaft verschoben. Neue URL verwenden.
Gefunden. Ressource temporär an anderer URL.
Siehe andere. Mit GET von anderer URL abrufen.
Nicht geändert. Cache-Version verwenden.
Proxy verwenden (veraltet).
Temporäre Weiterleitung mit gleicher Methode.
Permanente Weiterleitung mit gleicher Methode.
4xx Client-Fehler(29)
Fehlerhafte Anfrage. Server versteht Format nicht.
Nicht autorisiert. Authentifizierung erforderlich.
Bezahlung erforderlich. Für zukünftige Nutzung reserviert.
Verboten. Server versteht, lehnt aber ab.
Nicht gefunden. Ressource existiert nicht. Häufigster Code.
Methode nicht erlaubt. Methode wird nicht unterstützt.
Nicht akzeptabel. Entspricht nicht Accept-Header.
Proxy-Authentifizierung erforderlich.
Anfrage-Timeout. Server hat zu lange gewartet.
Konflikt. Anfrage kollidiert mit Serverstatus.
Verschwunden. Ressource dauerhaft gelöscht.
Länge erforderlich. Content-Length fehlt.
Vorbedingung fehlgeschlagen. Bedingungsheader nicht erfüllt.
Payload zu groß. Anfragekörper zu groß.
URI zu lang. URL zu lang.
Nicht unterstützter Medientyp. Format nicht unterstützt.
Bereich nicht erfüllbar. Angeforderter Bereich ungültig.
Erwartung fehlgeschlagen. Expect-Header nicht erfüllt.
Ich bin eine Teekanne. RFC 2324 Easter Egg.
Falsch geleitete Anfrage. An falschen Server gesendet.
Nicht verarbeitbare Entität. Syntax OK, Semantik fehlerhaft.
Gesperrt. Ressource gesperrt (WebDAV).
Abhängigkeit fehlgeschlagen. Vorherige Anfrage fehlgeschlagen (WebDAV).
Zu früh. Möglicherweise wiedergegebene Anfrage.
Upgrade erforderlich. Zu TLS wechseln.
Vorbedingung erforderlich. Bedingungsheader benötigt.
Zu viele Anfragen. Rate-Limit überschritten.
Anfrage-Header zu groß.
Aus rechtlichen Gründen nicht verfügbar.
5xx Server-Fehler(11)
Interner Server-Fehler. Unerwartete Bedingung.
Nicht implementiert. Funktionalität nicht unterstützt.
Fehlerhaftes Gateway. Ungültige Antwort vom Upstream.
Service nicht verfügbar. Temporär nicht verfügbar.
Gateway-Timeout. Wartezeit auf Upstream überschritten.
HTTP-Version nicht unterstützt.
Variante verhandelt auch. Konfigurationsfehler.
Speicher unzureichend (WebDAV).
Schleife erkannt (WebDAV).
Nicht erweitert. Weitere Erweiterungen erforderlich.
Netzwerk-Authentifizierung erforderlich.
Was sind HTTP-Statuscodes?
Die HTTP-Statuscode-Übersicht erklärt die Antwortcodes, mit denen Server einem Browser, einer App oder einem API-Client mitteilen, was aus einer Anfrage geworden ist. Codes der 2xx-Gruppe stehen meist für Erfolg, 3xx für Weiterleitungen, 4xx für clientseitige Probleme und 5xx für serverseitige Fehler. Für Entwickler, SEO-Arbeit und Support ist die genaue Bedeutung wichtig: 401 ist nicht dasselbe wie 403, 404 nicht dasselbe wie 410, und ein 301 hat andere Folgen als ein 302. Das Werkzeug hilft, Codes schnell einzuordnen und typische Ursachen oder nächste Prüfschritte in Logs, Headern und Routing zu erkennen. Bei gemeinsamer Nutzung sollten Eingaben, Annahmen und gewünschtes Ergebnis vorher klar sein, damit die Ausgabe nicht falsch interpretiert wird.
Anleitung
Schnellreferenz
- Klicke auf eine Statuscode-Karte, um sie zu kopieren
- Verwende die Suchleiste, um schnell bestimmte Codes zu finden
- Klicke auf Kategorietags, um nach Statustyp zu filtern
- Fahre mit der Maus über Codes, um detaillierte Beschreibungen anzuzeigen
Tipps zum Debugging
- Schau zuerst auf die Statusfamilie: 2xx Erfolg, 3xx Weiterleitung, 4xx Client-seitiges Problem, 5xx Server-seitiges Problem.
- Beim API-Debugging kombiniere den Statuscode mit dem Response-Body, den Headern, der Request-Methode und den Server-Logs – der Code allein erklärt selten das gesamte Problem.
Anwendungsfälle
Technisches Prinzip
HTTP-Statuscodes sind dreistellige Ganzzahlen, die in der Antwortstartzeile zurückgegeben werden und durch die HTTP-Semantik-Spezifikation definiert sind. Die aktuelle normative Referenz ist RFC 9110 (HTTP Semantics, Juni 2022), der die frühere RFC-7231-Reihe ersetzt, mit Erweiterungen in RFC 9111 (Caching), RFC 9112 (HTTP/1.1), RFC 9113 (HTTP/2) und RFC 9114 (HTTP/3). Die erste Ziffer definiert die Antwortklasse, sodass auch nicht erkannte Codes ein vorhersagbares Verhalten haben: 1xx Informational (vorläufig, die endgültige Antwort folgt), 2xx Erfolgreich, 3xx Umleitung (weitere Aktion des User Agent erforderlich), 4xx Client-Fehler (die Anfrage ist fehlerhaft oder kann nicht erfüllt werden) und 5xx Server-Fehler. Caches und Zwischenspeicher müssen unbekannte Codes als den generischen Klassencode x00 behandeln (z. B. wird ein unbekannter 4xx wie 400 behandelt), wodurch die Statusfamilie auch für proprietäre oder Erweiterungscodes aussagekräftig bleibt. Umleitungscodes tragen Methodenerhalt-Semantik, die historisch von der Absicht abwich. RFC 9110 §15.4 macht die Unterscheidung explizit: 301 Moved Permanently und 302 Found dürfen ein POST in ein GET umschreiben (das faktische Verhalten, auf das sich alle Browser in den späten 1990ern einigten, kodifiziert in RFC 7231); 307 Temporary Redirect und 308 Permanent Redirect verlangen vom User Agent, dieselbe Methode und denselben Body zu wiederholen. SEO-Tools übertragen typischerweise PageRank-äquivalentes Gewicht bei 301 und 308 und behandeln 302/307 als Erhaltung des Signals der Original-URL. Bedingte Codes 304 Not Modified und 412 Precondition Failed hängen von den Headern If-None-Match / If-Modified-Since / ETag / Last-Modified der Anfrage ab, und 206 Partial Content antwortet auf einen Range-Header mit einem Content-Range-Header und einem multipart/byteranges-Body, wenn mehrere Bereiche angefordert werden. Die 4xx- und 5xx-Klassen tragen Vertragsdetails in Headern. 401 Unauthorized muss eine WWW-Authenticate-Challenge enthalten, die akzeptierte Schemata auflistet (Bearer, Basic, Digest, Negotiate); ohne sie ist die Antwort technisch fehlerhaft. 405 Method Not Allowed muss einen Allow-Header mit den unterstützten Methoden enthalten. 429 Too Many Requests, 503 Service Unavailable und 301/307/308 mit Retry-After ermöglichen es dem Server, eine Verzögerung entweder in Sekunden (Retry-After: 120) oder als HTTP-Date (Retry-After: Wed, 21 Oct 2025 07:28:00 GMT) gemäß RFC 9110 §10.2.3 zu signalisieren. RFC 9110 deklariert 305 Use Proxy und 306 (reserviert/unbenutzt) als veraltet, bewahrt 418 I'm a teapot als dokumentierten RFC-2324-/RFC-7168-Scherzcode und reorganisiert 1xx, sodass nur 100 Continue und 101 Switching Protocols auf der HTTP/1.1-Ebene erforderlich sind; 102 Processing und 103 Early Hints (RFC 8297) sind optionale Erweiterungen, die hauptsächlich über CDN-Edge-Logik ausgespielt werden.
- Normative Referenz: RFC 9110 (HTTP Semantics, Juni 2022) ersetzt RFC 7230–7235; Erweiterungen in RFC 9111 (Caching), 9112 (HTTP/1.1-Leitungsformat), 9113 (HTTP/2), 9114 (HTTP/3).
- Unbekannte Codes degradieren auf den Klassencode (x00): ein unbekannter 4xx wird wie 400 gecacht und dargestellt, ein unbekannter 5xx wie 500 – dadurch wird die erste Ziffer zu einem verbindlichen Vertrag.
- Methodenerhalt: 301/302 erlauben historisch die POST → GET-Umschreibung (kodifiziert nach Browserdivergenz der frühen 1990er); 307/308 erfordern die Wiedergabe derselben Methode und desselben Bodys – verwende 308 für permanente API-Endpunktumzüge.
- 401 Unauthorized muss WWW-Authenticate tragen; 405 Method Not Allowed muss Allow tragen; das Fehlen dieser Header ist ein Spezifikationsverstoß, der wohlverhaltene HTTP-Clients stört.
- Retry-After (RFC 9110 §10.2.3) bei 429/503/301/307/308: akzeptiert entweder Delta-Sekunden (Retry-After: 120) oder HTTP-Date (Retry-After: Wed, 21 Oct 2025 07:28:00 GMT) – Clients sollten beide Formate parsen.
- Bedingtes Caching: 304 Not Modified antwortet auf If-None-Match / If-Modified-Since-Treffer ohne Body; 206 Partial Content antwortet auf Range mit Content-Range und entweder dem partiellen Body oder einem multipart/byteranges-Dokument.
- RFC 9110 deklariert 305 Use Proxy und 306 (reserviert) als veraltet, bewahrt 418 I'm a teapot aus RFC 2324 / RFC 7168 als Scherzcode und behandelt 102 Processing / 103 Early Hints (RFC 8297) als optionale 1xx-Erweiterungen, die viele Proxies entfernen.
Beispiele
2xx Erfolg - 200 OK und 204 No Content
200 OK GET /api/users -> Antwortkörper zurückgegeben
201 Created POST /api/posts -> neue Ressource im Location-Header
204 No Content DELETE /api/posts/42 -> Erfolg, leerer Körper
206 Partial Range-Anfrage für Video-Streaming oder fortsetzbare Downloads
RFC: RFC 7231 Abschnitt 6.3 definiert die 2xx-Erfolgsstatuscodes3xx Weiterleitungen - 301 vs 302 vs 304
301 Moved Permanently -> SEO-sicher, Browser cachen die neue URL dauerhaft
302 Found -> temporäre Weiterleitung, Ziel nicht cachen
304 Not Modified -> gecachte Kopie ist noch frisch (ETag/Last-Modified übereinstimmend)
307 Temporary Redirect -> wie 302, aber Methode darf NICHT wechseln (POST bleibt POST)
308 Permanent Redirect -> wie 301, aber bewahrt die Anfragemethode
RFC: RFC 7231 Abschnitt 6.4 definiert die 3xx-Weiterleitungscodes
RFC: RFC 7232 Abschnitt 4.1 definiert die Semantik von 304 Not Modified4xx Client-Fehler - Authentifizierung vs. Berechtigung
400 Bad Request Fehlerhaftes JSON, fehlendes Pflichtfeld
401 Unauthorized Fehlendes oder ungültiges Token - Aufrufer muss sich authentifizieren
403 Forbidden Authentifiziert, aber nicht berechtigt, auf diese Ressource zuzugreifen
404 Not Found Ressource existiert nicht (oder wird aus Sicherheitsgründen so vorgegeben)
409 Conflict Doppelter Schlüssel, optimistische Sperrversionsabweichung
429 Too Many Reqs Rate Limit erreicht - siehe Retry-After-Header
RFC: RFC 7231 Abschnitt 6.5 definiert die 4xx-Client-Fehlercodes
RFC: RFC 6585 Abschnitt 4 definiert 429 Too Many Requests5xx Serverfehler - Debugging einer Upstream-Komponente
500 Internal Server Error Unbehandelte Ausnahme im Anwendungscode - Logs prüfen
502 Bad Gateway Nginx/Upstream erhielt eine ungültige Antwort vom Backend
503 Service Unavailable Wartung, Überlastung oder Anwendung startet gerade
504 Gateway Timeout Upstream antwortete nicht innerhalb des Proxy-Timeouts
RFC: RFC 7231 Abschnitt 6.6 definiert die 5xx-Serverfehlercodes
Schnelle Einordnung: 5xx = unser Fehler, 4xx = Fehler des AufrufersEchte curl-Sitzung mit mehreren Codes
$ curl -I https://example.com/old-page
HTTP/2 301
location: https://example.com/new-page
$ curl -I https://example.com/admin
HTTP/2 401
www-authenticate: Bearer realm="api"
$ curl -X POST https://example.com/api/posts -d '{}'
HTTP/2 422
content-type: application/json
Hinweis: 422 Unprocessable Entity ist eine WebDAV-Erweiterung (RFC 4918), die für Validierungsfehler verwendet wirdFAQ
Was bedeuten die Klassen 1xx, 2xx, 3xx, 4xx und 5xx?
1xx ist informativ (in der Praxis selten). 2xx bedeutet, die Anfrage war erfolgreich. 3xx ist eine Weiterleitung — der Client soll einer anderen URL folgen. 4xx ist ein clientseitiges Problem (fehlerhafte Anfrage, fehlende Auth, fehlende Ressource). 5xx ist ein serverseitiges Problem (die Anfrage sah okay aus, aber der Server konnte sie nicht erfüllen). Prüfe beim Lesen einer Logzeile immer zuerst die Klasse.
Was ist der Unterschied zwischen 301 und 302?
301 Moved Permanently teilt Clients und Suchmaschinen mit, dass die Ressource dauerhaft umgezogen ist — Browser cachen die Weiterleitung aggressiv und SEO-Linkkraft wird auf die neue URL übertragen. 302 Found ist eine temporäre Weiterleitung; Clients sollen sie nicht langfristig cachen. Nutze 308 für permanente Weiterleitungen, wenn die Request-Methode erhalten bleiben muss, und 307 für temporäre Weiterleitungen unter derselben Vorgabe.
Wann gebe ich 401 vs. 403 zurück?
401 Unauthorized bedeutet, der Client hat sich nicht authentifiziert oder die gesendeten Anmeldedaten sind ungültig — die Antwort sollte einen WWW-Authenticate-Header enthalten. 403 Forbidden bedeutet, der Server weiß, wer der Client ist, und verweigert das Ausliefern dieser Ressource trotzdem. Einloggen behebt 401; Einloggen behebt nicht 403.
Sollte ich 404 oder 410 für nicht mehr existierende Ressourcen verwenden?
404 Not Found bedeutet „Ich finde das nicht; es könnte irgendwo existieren oder zurückkommen.“ 410 Gone bedeutet „Diese Ressource war hier, sie wurde absichtlich entfernt, suche nicht erneut nach ihr.“ Suchmaschinen entfernen 410-URLs schneller aus dem Index als 404, also ist 410 die richtige Wahl für stillgelegte Seiten, die du nicht erneut crawlen lassen willst.
Wie lese ich einen Statuscode beim Debuggen einer API?
Lies zuerst die Klasse (4xx vs. 5xx sagt dir, auf welcher Seite du suchen musst), dann den spezifischen Code, dann den Response-Body. Der Body trägt meist die eigentliche Fehlermeldung und einen internen Fehlercode; der HTTP-Status ist nur die Kategorie. Inspiziere immer Header wie Retry-After, WWW-Authenticate und Location zusätzlich zum Status.
Schaden Nicht-2xx-Codes der SEO?
Manche schon, manche nicht. Lang anhaltende 5xx-Antworten signalisieren eine unzuverlässige Seite und Suchmaschinen reduzieren irgendwann die Crawl-Frequenz. 301/308-Weiterleitungen geben Linkkraft weiter; 302/307 nicht. 410 entfernt Seiten aus dem Index; 404er bleiben länger hängen. 200 mit einem Soft-404-Body (eine echte „nicht gefunden“-Seite, die 200 zurückgibt) ist schlechter für SEO als ein echtes 404, weil es den Index mit leeren Seiten füllt.
Wofür sind 418, 451 und andere ungewöhnliche Codes?
418 „I'm a teapot“ ist der berühmte Aprilscherz-Code aus RFC 2324 — echte Dienste sollten ihn in Production niemals zurückgeben. 451 Unavailable For Legal Reasons signalisiert, dass die Ressource aufgrund einer rechtlichen Forderung blockiert ist (benannt nach Bradburys Fahrenheit 451). 429 Too Many Requests signalisiert Rate Limiting und sollte mit einem Retry-After-Header gepaart werden. 503 Service Unavailable ist der richtige Code für geplante Wartungsarbeiten.