HTTP-Statuscode-Nachschlag
Nachschlag für jeden HTTP-Statuscode (1xx–5xx), um seinen offiziellen Namen, Bedeutung, häufige Ursachen und Lösungen zu sehen. Deckt alle 60+ Standard-Statuscodes mit praktischen Erklärungen für Entwickler ab.
59 status codes
So verwenden Sie HTTP-Statuscode-Nachschlag
- 1Geben Sie einen beliebigen HTTP-Statuscode ein (z. B. 404, 500, 301) oder suchen Sie nach Schlüsselwort.
- 2Die offizielle Statusbegründung und vollständige Beschreibung werden angezeigt.
- 3Häufige Ursachen und empfohlene Lösungen werden für jeden Fehlercode bereitgestellt.
- 4Durchsuchen Sie alle Codes nach Kategorie: 1xx Informativ, 2xx Erfolg, 3xx Umleitung, 4xx Client-Fehler, 5xx Server-Fehler.
ZenovayAnalytics
Analytics, für Gründer gebaut.
- Besucher-Tracking in Echtzeit
- Datenschutz zuerst, kein Cookie-Banner
- In zwei Minuten eingerichtet
Verwandte Tools
JSON-Formatter und Validator
Formatieren, validieren und verschönern Sie JSON-Daten mit Syntaxhervorhebung und Fehlererkennung.JWT-Decoder
Dekodieren und inspizieren Sie JWT-Token. Zeigen Sie Header, Payload und überprüfen Sie Signaturen.Base64 Encode/Decode
Kodieren Sie Text in Base64 oder dekodieren Sie Base64 zurück in Text. Unterstützt UTF-8 und Binärdaten.URL Codierungstool
Codieren oder decodieren Sie URL-Komponenten. Verarbeiten Sie Sonderzeichen, Abfragezeichenfolgen und vollständige URLs.Häufig gestellte Fragen
Was ist der Unterschied zwischen 401 und 403?▾
401 Unauthorized bedeutet, dass der Anfrage die gültige Authentifizierung fehlt – Sie sind nicht angemeldet oder Ihre Anmeldedaten sind ungültig. Der Server sagt "wer sind Sie?" 403 Forbidden bedeutet, dass der Server weiß, wer Sie sind (authentifiziert), aber Sie haben keine Berechtigung, auf diese Ressource zuzugreifen. Der Server sagt "ich weiß, wer Sie sind, aber Sie können darauf nicht zugreifen." Ein häufiger Fehler: Rückgabe von 401 für "nicht angemeldet" und 403 für "angemeldet, aber ohne Berechtigung". Geben Sie immer 401 mit einem WWW-Authenticate-Header zurück, um anzuzeigen, dass Anmeldedaten hilfreich sind.
Was ist der Unterschied zwischen 301 und 302?▾
301 Moved Permanently teilt Clients und Suchmaschinen mit, dass die Ressource dauerhaft umgezogen ist – aktualisieren Sie Ihre Lesezeichen. Suchmaschinen übertragen SEO-Ranking (Link-Equity) auf die neue URL. 302 Found (temporär) teilt Clients mit, diese Anfrage von der neuen URL zu holen, aber die ursprüngliche URL für zukünftige Anfragen zu verwenden. Suchmaschinen übertragen für 302s nicht die volle SEO-Equity. Verwenden Sie 301 für dauerhafte URL-Änderungen (HTTPS-Migration, Domain-Wechsel). Verwenden Sie 302 für A/B-Tests, temporäre Wartungsseiten oder Login-Weiterleitungen.
Warum unterscheidet sich 404 von 410?▾
404 Not Found bedeutet, dass die Ressource nicht gefunden werden kann – sie kann existiert haben oder nicht. Der Client sollte in der Zukunft erneut versuchen. 410 Gone teilt explizit mit, dass die Ressource absichtlich entfernt wurde und nicht mehr verfügbar sein wird. 410 ist besser für SEO beim permanenten Entfernen von Inhalten – Googlebot de-indexiert 410-Seiten schneller als 404-Seiten. Verwenden Sie 410 für gelöschte Blog-Posts, eingestellte Produkte oder geschlossene Konten, wenn Sie eine permanente Entfernung signalisieren möchten.
Was verursacht 502 vs 503 vs 504?▾
502 Bad Gateway: Ihr Proxy/Load Balancer erhielt eine ungültige Antwort vom Backend-App-Server (z.B. App-Crash, ungültige Rückgabe). 503 Service Unavailable: Der Backend-App ist aktiv, aber lehnt Verbindungen ab – typischerweise überlastet, im Wartungsmodus oder verbindungslos. 504 Gateway Timeout: Der Proxy wartete zu lange auf eine Antwort des Backends – das Backend läuft, ist aber zu langsam (z.B. langsame Datenbankabfrage). Häufige Fixes: 502=App-Server neustarten; 503=Last reduzieren oder auf Wartung warten; 504=langsame Abfragen optimieren oder Timeout erhöhen.
Wann sollte ich 422 vs 400 verwenden?▾
400 Bad Request ist für syntaktische Fehler – die Anfrage selbst ist fehlerhaft (ungültiges JSON, falscher content-type, fehlende erforderliche Header). 422 Unprocessable Content (ehemals Unprocessable Entity) ist für semantische Validierungsfehler – das Anfrage-Format ist korrekt, aber die Daten scheitern der Business-Validierung (E-Mail-Format ungültig, Alter ist negativ, Benutzername bereits vergeben). Moderne REST-APIs bevorzugen 422 für Validierungsfehler mit strukturiertem Body, der jeden Feld-Fehler auflistet. Rails verwendet standardmäßig 422 für Formularvalidierungsfehler. GraphQL-APIs geben typischerweise 200 mit Errors im Response-Body zurück.