Schnittstellenfehler eingrenzen
Bei Codes wie 401, 403, 409 oder 422 schnell die Bedeutung und den typischen Kontext nachschlagen.
Guide
Die Seite „HTTP-Statuscodes“ ist eine fest in die Anwendung eingebaute Übersicht; gesucht wird nach Statuscode, englischem Namen, Bedeutung oder Beschreibung, gefiltert nach 1xx (Information), 2xx (Erfolg), 3xx (Umleitung), 4xx (Client-Fehler) und 5xx (Server-Fehler). Angezeigt wird statisches Wissen – an die eingegebene Domain oder Schnittstelle geht keine HTTP-Anfrage.
Aktualisiert am 2026-09-101 min read
404, „Zeitüberschreitung“ oder einen Statusnamen eingeben oder das Feld leer lassen, um alles zu durchblättern.| Eingabe | Ausgabe | Hinweis |
|---|---|---|
404 |
Erläuterung zu 404 Not Found | exakte Suche nach der Nummer |
| „Umleitung“ | passende 3xx-Beschreibungen | Textsuche |
| 5xx ausgewählt | nur die Server-Fehlerklasse | lokaler Filter |
HTTP_STATUS-Liste; der Umfang ändert sich mit der App-Version und wird nicht online mit dem IANA-Register abgeglichen.fetch; sie kann dir nicht sagen, welchen Statuscode eine Website gerade zurückgibt.Bei Codes wie 401, 403, 409 oder 422 schnell die Bedeutung und den typischen Kontext nachschlagen.
Nach 2xx/3xx/4xx/5xx gruppiert durchblättern und ein Grundverständnis des Protokolls aufbauen.
Nein. Die Seite hat keinerlei Netzwerkzugriff und sieht nur in der lokalen Statustabelle nach.
Nein, es sind Daten, die mit der App ausgeliefert werden.
Suchbegriffe filtern nur die lokale statische Tabelle; es werden keine Netzwerkanfragen gesendet.
Aktualisiert am 2026-09-10
Alle Statuscodes von 1xx bis 5xx mit Bedeutung und typischen Einsatzfällen
Dieses Werkzeug ist noch nicht vollständig übersetzt; einige Inhalte nutzen die Ausgangssprache oder die Rückfallsprache.
Der Server hat die Anfrage-Header erhalten; der Client sollte den Body weiter senden. Häufig bei großen Uploads, die mit Expect: 100-continue abgesichert werden.
Der Server stimmt dem Protokollwechsel zu, meist beim WebSocket-Upgrade (Upgrade: websocket).
WebDAV-Erweiterung: Die Anfrage ist eingegangen und wird verarbeitet, aber es gibt noch keine Antwort. Verhindert, dass Clients in einen Timeout laufen.
Gibt einen Teil der Header schon vor der endgültigen Antwort zurück, oft mit einem Link-Header, damit der Browser CSS/JS-Ressourcen vorzeitig lädt.
Die Anfrage war erfolgreich. GET liefert den Inhalt der Ressource, POST das Verarbeitungsergebnis. Der häufigste Statuscode.
Die Ressource wurde erfolgreich erstellt; typisch als Antwort auf POST/PUT, meist mit einem Location-Header, der auf die neue Ressource zeigt.
Die Anfrage wurde angenommen, ist aber noch nicht fertig verarbeitet. Geeignet für asynchrone Aufgaben wie Warteschlangen oder Massenimporte.
Die zurückgegebenen Metainformationen stammen aus einer lokalen oder fremden Kopie (etwa von einem verändernden Proxy) und nicht vom Originalserver.
Erfolgreich verarbeitet, aber ohne Inhalt in der Antwort. Häufig nach einem erfolgreichen DELETE oder einem Formular-Speichern ohne Seitenwechsel.
Erfolgreich verarbeitet; der Client soll seine Ansicht zurücksetzen (etwa ein Formular leeren). Wird praktisch kaum verwendet.
Eine Range-Anfrage war erfolgreich und ein Teil der Ressource wird zurückgegeben. Video-Springen und fortsetzbare Downloads bauen darauf auf (Range-Header).
WebDAV-Erweiterung: Eine Anfrage enthält mehrere Operationen, deren Status jeweils im XML-Body angegeben wird.
WebDAV-Erweiterung: Die gebundenen Mitglieder wurden bereits in einer früheren Antwort aufgezählt und werden nicht erneut aufgelistet.
Der Server hat eine GET-Anfrage für die Ressource erfüllt; die Antwort ist das Ergebnis angewandter Instanz-Manipulationen (Delta-Kodierung).
Die Ressource hat mehrere Darstellungen (etwa Sprachvarianten); Client oder Nutzer müssen eine davon wählen.
Die Ressource ist dauerhaft unter einer neuen Adresse erreichbar; Suchmaschinen aktualisieren ihren Index. Üblich bei Domainwechsel und HTTP zu HTTPS.
Die Ressource liegt vorübergehend unter einer anderen Adresse. Ältere Clients ändern dabei POST zu GET; wenn die Methode erhalten bleiben soll, 307 verwenden.
Der Client soll das Ergebnis mit GET unter einer anderen Adresse abrufen; typisch für den Sprung zur Ergebnisseite nach dem Absenden eines Formulars (PRG-Muster).
Die Ressource hat sich seit der letzten Anfrage nicht geändert, der lokale Cache kann weiterverwendet werden. Zusammen mit ETag / Last-Modified für bedingte Anfragen.
(Veraltet) Die Ressource muss über den angegebenen Proxy erreicht werden. Moderne Browser unterstützen das aus Sicherheitsgründen nicht mehr.
Wie 302, aber Methode und Body der Anfrage dürfen beim Weiterleiten nicht geändert werden (POST bleibt POST).
Wie 301, aber Methode und Body der Anfrage bleiben erhalten – geeignet für den dauerhaften Umzug einer API.
Der Server kann die Anfrage nicht verstehen: fehlende Parameter, fehlerhaftes JSON, ungültige Syntax. Der Client sollte die Anfrage prüfen.
Zugangsdaten fehlen oder sind ungültig (etwa ein abgelaufenes Token). Semantisch bedeutet das: nicht angemeldet; der Nutzer sollte zur Anmeldung geführt werden.
Reservierter Statuscode, den manche APIs nutzen, um ein aufgebrauchtes Kontingent oder ein nötiges Abo zu melden.
Die Identität ist bekannt, aber es fehlt die Berechtigung für die Ressource (etwa ein normaler Nutzer an einer Admin-Schnittstelle). Anders als bei 401 geht es um Autorisierung.
Die angeforderte Ressource existiert nicht: falsche URL oder gelöschte Ressource. Der bekannteste Statuscode.
Die Ressource unterstützt diese HTTP-Methode nicht (etwa POST an einer Nur-Lese-Schnittstelle). Die Antwort sollte im Allow-Header die erlaubten Methoden nennen.
Der Server kann kein Format liefern, das zum Accept-Header passt (der Client akzeptiert nur XML, der Server hat aber nur JSON).
Wie 401, aber es ist zuerst eine Authentifizierung am Proxy-Server nötig.
Der Server hat beim Warten auf die vollständige Anfrage das Zeitlimit überschritten (langsames Netz oder abgebrochener Client). Der Client kann es später erneut versuchen.
Die Anfrage steht im Konflikt mit dem aktuellen Zustand der Ressource: doppelte Erstellung, gleichzeitige Änderungen und so weiter.
Die Ressource existierte, wurde aber endgültig entfernt und kommt nicht zurück. Eindeutiger als 404 und hilft Suchmaschinen beim Entfernen aus dem Index.
Der Server verlangt, dass die Anfrage einen Content-Length-Header enthält.
Eine Bedingung im Header wie If-Match ist nicht erfüllt – oft als optimistisches Sperren, das das Überschreiben einer fremd geänderten Ressource verhindert.
Der Anfrage-Body überschreitet das Serverlimit, typisch bei zu großen Uploads (etwa nginx client_max_body_size).
Die angeforderte URL ist länger, als der Server verarbeitet; meist durch zu viele GET-Parameter. Besser POST verwenden.
Das Format des Anfrage-Bodys wird nicht unterstützt, etwa ein Formular-Body an eine Schnittstelle, die application/json erwartet.
Der im Range-Header angeforderte Bereich liegt außerhalb der tatsächlichen Größe der Ressource; häufig, wenn die lokalen Daten eines fortgesetzten Downloads nicht mehr zum Serverfile passen.
Der Server kann die Anforderung im Expect-Header nicht erfüllen (etwa 100-continue wird nicht unterstützt).
Ein Aprilscherz von 1998 (HTCPCP-Protokoll): Die Teekanne weigert sich, Kaffee zu kochen. Manche Seiten nutzen ihn als spielerische Anti-Scraper-Antwort.
Die Anfrage erreichte einen Server, der keine Antwort erzeugen kann; oft durch HTTP/2-Verbindungswiederverwendung zum falschen virtuellen Host.
Die Anfrage ist syntaktisch korrekt, aber inhaltlich ungültig: Eine Feldprüfung schlägt fehl (etwa eine falsche E-Mail-Adresse). REST-APIs nutzen das für Formularfehler.
WebDAV-Erweiterung: Die Ressource ist gesperrt, die aktuelle Operation kann nicht ausgeführt werden.
WebDAV-Erweiterung: Weil eine vorherige Anfrage fehlgeschlagen ist, kann die aktuelle Anfrage nicht abgeschlossen werden.
Der Server möchte keine frühen Daten verarbeiten, die wiederholt werden könnten (TLS 1.3 0-RTT), um Replay-Angriffe zu vermeiden.
Der Server lehnt die Verarbeitung mit dem aktuellen Protokoll ab und verlangt ein Upgrade; der Upgrade-Header nennt das Zielprotokoll.
Der Server verlangt einen Bedingungs-Header (etwa If-Match), damit Clients optimistisches Sperren nutzen und keine Aktualisierungen verloren gehen.
Das Ratenlimit wurde erreicht. Die Antwort kann im Retry-After-Header nennen, wann ein neuer Versuch möglich ist – der Standard-Statuscode für API-Drosselung.
Die Gesamtgröße der Anfrage-Header oder ein einzelnes Header-Feld überschreitet das Limit, häufig durch zu groß gewordene Cookies.
Die Ressource wird aus rechtlichen Gründen vorenthalten (Urheberrecht, behördliche Sperre). Die Nummer verweist auf den Roman Fahrenheit 451.
Bei der Verarbeitung ist ein unerwarteter Fehler aufgetreten (nicht abgefangene Ausnahme, Codefehler). Die Server-Logs sind zu prüfen.
Der Server unterstützt diese Methode oder Funktion nicht, etwa PATCH an einen Server, der nur GET/POST kann.
Gateway oder Reverse-Proxy haben vom vorgelagerten Server eine ungültige Antwort erhalten; oft bei abgestürztem Backend oder abgelehnter nginx-Upstream-Verbindung.
Der Server ist vorübergehend überlastet oder in Wartung; dazu passt der Retry-After-Header. Häufig beim Skalieren, bei Deployments und beim Circuit Breaker.
Gateway oder Proxy haben beim Warten auf die Antwort des vorgelagerten Servers das Zeitlimit überschritten; oft wegen langsamer Backend-Verarbeitung oder einer langsamen Datenbankabfrage.
Der Server unterstützt die in der Anfrage verwendete HTTP-Version nicht.
Fehlkonfiguration der Inhaltsaushandlung: Die gewählte Variante nimmt selbst an der Aushandlung teil, sodass eine Schleife entsteht.
WebDAV-Erweiterung: Der Server hat nicht genug Platz für das, was die Anfrage speichern soll (etwa eine volle Festplatte).
WebDAV-Erweiterung: Bei der Verarbeitung wurde eine Endlosschleife erkannt (etwa ein Zyklus in Bindungen).
Der Anfrage fehlen Erweiterungen, die der Server verlangt; sie muss erweitert werden, bevor ein neuer Versuch möglich ist (sehr selten).
Erst nach einer Authentifizierung auf Netzwerkebene ist der Zugang möglich; typisch ist das Anmeldeportal im Hotel- oder Flughafen-WLAN.