4xx-Statuscodes erklärt: was Client-Fehler wirklich bedeuten

Was die 4xx-Klasse aussagt

RFC 9110 definiert die 4xx-Klasse als "Client Error": Der Server geht davon aus, dass der Client einen Fehler gemacht hat. Das deckt eine Anfrage nach etwas Nicht-Existentem ab, eine Anfrage ohne die benötigten Anmeldeinformationen, eine Anfrage, die der Server aus Richtliniengründen ablehnt, und eine Anfrage, die missgebildet oder zu groß ist.

Drei Eigenschaften der Klasse sind wichtig, während Sie eine debuggen:

• Ein 4xx ist eine endgültige Antwort für diesen so gesendeten Request. Das identische Wiederholen des Requests erzeugt normalerweise denselben Code.
• Der Antwort-Body soll eine für Menschen lesbare Erklärung sein. Deshalb gibt es benutzerdefinierte Fehlerseiten, und deshalb ist eine leere 404-Seite eine vertane Gelegenheit.
• Manche 4xx-Antworten sind standardmäßig cachefähig. RFC 9111 listet 404, 405, 410 und 414 unter den Codes, die ein Cache heuristisch speichern darf, ein falscher 404 kann also den Fehler überdauern, der ihn verursacht hat.

Die 4xx-Codes, denen Sie begegnen werden

• 400 Bad Request: Der Request ist missgebildet, und der Server kann ihn nicht parsen. Häufig ein fehlerhafter Query-String, ein übergroßer Cookie-Header oder ein defekter Proxy vor der Anwendung.
• 401 Unauthorized: Authentifizierung ist erforderlich und entweder fehlend oder ungültig. Der Server muss einen WWW-Authenticate-Header senden, der dem Client sagt, wie er sich authentifizieren soll.
• 403 Forbidden: Der Server hat den Request verstanden und lehnt ihn ab. Anmeldeinformationen helfen hier nicht, denn die Ablehnung ist eine Richtlinienentscheidung, kein Authentifizierungsfehler.
• 404 Not Found: Unter dieser URL existiert keine aktuelle Repräsentation, oder der Server gibt nicht zu, dass eine existiert. Ausführlich behandelt in der 404-Anleitung.
• 405 Method Not Allowed: Die URL existiert, aber nicht für diese Methode. Der Server muss die von ihm akzeptierten Methoden in einem Allow-Header auflisten.
• 408 Request Timeout: Der Client hat zu lange gebraucht, um den Request zu senden. Anders als ein 504, bei dem die Verzögerung hinter dem Server liegt.
• 410 Gone: Die Ressource existierte und wurde absichtlich entfernt, und das gilt als dauerhaft.
• 413 Content Too Large und 414 URI Too Long: Der Request hat ein konfiguriertes Limit überschritten, meist eine Upload-Obergrenze oder ein Header-Größenlimit.
• 429 Too Many Requests: Ein Rate-Limit wurde erreicht. Dieser trifft Monitoring-Aufbauten besonders häufig.

Wann ein 4xx eigentlich eine Serverfehlkonfiguration ist

Die Bezeichnung "Client Error" betrifft Protokollrollen, nicht Schuldzuweisung. Die meisten 4xx-Codes, die auf einer gesunden Produktionswebsite auftauchen, werden durch etwas auf Ihrer Seite verursacht. Eine Rewrite- oder Routing-Regel, die nicht mehr greift, verwandelt gültige URLs in einem ganzen Verzeichnis in 404er, und das Erkennungszeichen ist ein 404 bei vielen URLs gleichzeitig statt bei einer einzigen. Ein Build, der aufhört, ein gehashtes Asset auszuliefern, macht dasselbe auf Dateiebene: Jede Seite fordert eine Datei an, die 404 zurückgibt, die Seite rendert also, wirkt aber kaputt.

Sicherheitsschichten erklären den Großteil des Rests. Eine WAF-Regel, ein Bot-Filter oder eine Geo-Sperre kann echtem Traffic 403 zurückgeben, und das wird leicht übersehen, weil es meist für die Büro-IP-Adresse durchgeht. Eine Auth-Änderung, die eine Seite mit 401 antworten lässt, obwohl sie öffentlich sein sollte, ist ein vollständig serververursachter 4xx. Ebenso ein 400 oder 413 von einem Reverse-Proxy, dessen Header- oder Body-Limit kleiner ist als das der Anwendung, für einen Request, den die App akzeptiert hätte.

Wie Sie einen 4xx auf Ihrer eigenen Website diagnostizieren

1. Lesen Sie zuerst den genauen Code und die Header. Urteilen Sie nicht nach der Fehlerseite, die generisch sein kann:

   curl -sS -o /dev/null -D - https://example.com/broken-page

   Das zeigt die Statuszeile plus Allow, WWW-Authenticate, Retry-After und jeden Server- oder CDN-Identifikations-Header.
2. Entscheiden Sie, ob es eine URL oder ein Muster ist. Eine URL verweist auf einen Link oder eine gelöschte Seite. Ein ganzer Pfad-Präfix verweist auf Routing, Berechtigungen oder ein Deployment.
3. Prüfen Sie, wer geantwortet hat. Vergleichen Sie die Antwort vom CDN-Edge mit der Antwort vom Ursprung. Ein 403, das nur am Edge existiert, ist eine WAF- oder Bot-Regel, nicht Ihre Anwendung.
4. Probieren Sie eine andere Client-Identität. Ein anderer User-Agent, eine nicht authentifizierte Sitzung oder ein anderes Netzwerk kann den Code von 403 auf 200 ändern, was die Blockade sofort lokalisiert.
5. Lesen Sie die Server-Log-Zeile für diesen Request. Webserver- und Anwendungslogs zeichnen auf, welche Regel oder welcher Handler den Code erzeugt hat. Das ist der Schritt, der die Untersuchung meist beendet.
6. Beheben, dann Caches leeren. Weil mehrere 4xx-Codes cachefähig sind, kann eine korrigierte Seite weiterhin den alten Fehler aus einem CDN- oder Browser-Cache ausliefern, bis der Eintrag ungültig gemacht wird.

Die 4xx-Seiten finden, die Sie nie besuchen

Ein 4xx legt keinen Server lahm, weshalb es unbemerkt bleibt. Die Website lädt, die Startseite ist in Ordnung, und ein Bereich gibt für alle außer Ihnen 404 oder 403 zurück. Eine geplante HTTP-Prüfung vergleicht den erhaltenen Code mit dem erwarteten, sodass eine Seite, die statt 200 plötzlich 403 antwortet, einen Alarm auslöst, statt auf ein Support-Ticket zu warten. Woher die Prüfung läuft, spielt ebenfalls eine Rolle. HostTracker prüft von über 300 Prüfpunkten in 158 Städten, sodass eine Geo-Sperre oder eine regionale WAF-Regel als echter Unterschied zwischen Standorten sichtbar wird statt als Rätsel. Ist der fehlschlagende Code stattdessen 500, 502 oder 503, liegt die Ursache serverseitig, und die Anleitung zur 5xx-Familie ist der richtige Ausgangspunkt.