HTTP-Status-Codes: Cloudflare, nginx, Snippets

Was macht das HTTP-Status-Codes-Tool?

Das Tool ist ein durchsuchbarer Referenz-Catalog für HTTP-Status-Codes. Es deckt RFC 9110 vollständig ab, also alle 1xx-Informational-, 2xx-Success-, 3xx-Redirection-, 4xx-Client-Error- und 5xx-Server-Error- Codes, und ergänzt um die Plattform-spezifischen Codes, die in der RFC-Registry fehlen, im Production- Log aber täglich auftauchen: Cloudflare 520-530, nginx 444 und 494-499, IIS 440 und 449, AWS Application Load Balancer 460/463 und CloudFront 561.

Pro Code zeigt das Tool: die kanonische Reason-Phrase, eine technische Erklärung in zwei bis vier Sätzen, die typischen HTTP-Methoden (POST liefert tendenziell 201, GET tendenziell 200), den Link zur Spezifikation (RFC, Cloudflare-Docs, nginx-Source) und einen Link zur Wikipedia-Übersicht für editorialen Kontext.

Welche Plattform-Codes deckt das Tool ab?

MDN dokumentiert nur den IANA-registrierten Standard. Tools, die im Production-Stack vorkommen, emittieren aber regelmäßig nicht-standardisierte Codes:

• Cloudflare 520-527 und 530, die komplette „Edge konnte den Origin nicht erreichen”-Familie. 521 (Origin offline), 522 (Connection-Timeout), 523 (Origin-DNS-Fehler), 524 (Origin-Antwort > 100 s), 525 und 526 (Origin-SSL-Probleme), 527 (Railgun-Fehler), 530 (Wrapper für 1xxx-Fehler).
• nginx 444 und 494-499, interne Codes aus der nginx-Source: 444 (Connection still gedroppt), 494 (Header zu groß), 495 und 496 (Client-Cert-Probleme), 497 (HTTP-auf-HTTPS-Port), 499 (Client hat Verbindung geschlossen).
• IIS 440 und 449, Microsoft-spezifische Codes: 440 (Login-Timeout), 449 (Retry-With).
• AWS Application Load Balancer 460/463 und CloudFront 561, Cloud-Provider-Edge-Codes für Client-Timeout, übergroße X-Forwarded-For-Chain, Lambda@Edge-Auth-Fail.

Der Filter „Nur Plattform-Codes” blendet den RFC-Standard aus und zeigt nur diese Welt, nützlich, wenn du nach einem konkreten 5xx-Vorfall im Cloudflare-Dashboard nachschlägst.

Was sind Verwechslungs-Cards?

Vier Code-Paare werden 2026 am häufigsten verwechselt, das Tool blendet automatisch eine Vergleichs-Karte ein, sobald du einen der Codes auswählst:

• 401 vs 403, Authentifizierung (kein Login) vs Autorisierung (Login da, aber kein Recht).
• 301 vs 302 vs 307 vs 308, Permanenz × Methoden-Erhalt als Wahrheits-Tabelle. 308 = permanent + method-preserving, die moderne Wahl.
• 400 vs 422, HTTP-Layer-Fehler (Syntax, Framing) vs Geschäfts­regel-Fehler (Validierung, Conflict). 422 nutzen, wenn das JSON syntaktisch ok ist aber das E-Mail-Feld ungültig.
• 502 vs 503 vs 504, Upstream defekt vs Origin überlastet vs Upstream stumm. Die drei Gateway-Fehler sehen ähnlich aus, haben aber unterschiedliche Root-Cause-Diagnosen.

Pro Cluster gibt es eine ein-bis-zwei-Satz-Zusammenfassung und Buttons zu den Peer-Codes, Click-Through ohne URL-Wechsel.

Wie funktioniert der HTTP-Methoden-Filter?

Jeder Code in der Datenbank trägt eine Liste „typische HTTP-Methoden, die diesen Code erzeugen”. Der Filter „HTTP-Methode” blendet die Liste auf eine Methode ein: Klick „POST” zeigt nur Codes, die nach einem POST sinnvoll sind, also 200, 201, 202, 204, 303, 307, 400, 409, 422, 429, 500. Klick „GET” zeigt die GET-typischen Codes: 200, 206, 301, 304, 404, 410.

Das ist die inverse Sicht zur Detail-Karte: Dort sagt jeder Code „diese Methoden lösen mich aus”, der Filter sagt „diese Methode liefert mir folgende Codes”.

Welche Snippet-Sprachen unterstützt der Export?

Sechs Zielsprachen, alle pure-client generiert:

• TypeScript-Enum, export enum HttpStatus { NOT_FOUND = 404, … } mit JSDoc-Kommentaren.
• Python-Dict, HTTP_STATUS_CODES = { 404: "Not Found", … } als Lookup-Map.
• Go-Const-Block, const ( StatusNot_Found = 404 … ) im idiomatic Go-Style.
• Rust-Enum, #[repr(u16)] pub enum HttpStatus { Not_Found = 404, … } mit u16-Repräsentation.
• Java-Record, public record HttpStatus(int code, String name) plus statische Final-Constants.
• Ruby-Module, module HttpStatus NOT_FOUND = 404 … end als Konstanten-Container.

Per Default emittiert der Export alle Codes, Standard plus Plattform-Codes. Du kannst die Auswahl per „Nur RFC-Standard”-Toggle einschränken, dann erscheint die Plattform-Welt nicht im generierten Code. Beide Snippets sind sauber kommentiert und können direkt in einen Codebase eingefügt werden, keine Tests, keine Abhängigkeiten, keine Compiler-Warnungen erwartet.

Warum läuft die Suche pure-client ohne Tracking?

Dieses Tool sendet keinen Request an einen Server. Die komplette Status-Code-Datenbank ist im JavaScript- Bundle eingebettet, die Suche läuft per String.prototype.toLowerCase und includes, die Snippet- Generierung per Template-String. Keine API-Calls, keine Telemetrie, keine Cookies, kein localStorage.

Mehr im OWASP Logging Cheat Sheet zur Frage, was eine Tool-Suche eigentlich preisgibt, und warum es bei sicherheits-relevanten Lookups (Status-Code-Recherche während eines Incidents) wichtig ist, dass die Suche nicht in einem fremden Log landet. Die IANA HTTP Status Code Registry ist die kanonische Quelle für IANA-registrierte Codes; alles darüber hinaus stammt direkt aus den Plattform-Dokumentationen (Cloudflare 5xx-Errors, nginx HTTP request processing, Microsoft IIS HTTP status codes).