Zum Inhalt springen
Kostenloses Tool

HTTP Status Codes: Liste & Bedeutung

HTTP Status Codes als durchsuchbare Liste: Gib 404, 403, 500, 502 oder „Weiterleitung“ ein und lies, was der HTTP-Code bedeutet, woran er liegt und wie du ihn behebst. 70 Codes von 100 bis 526, mit nginx- und Apache-Beispielen zum Kopieren, den Cloudflare-Fehlern 520 bis 526 und den nginx-Codes 444 und 499. Kostenlos und ohne Anmeldung – die Suche läuft komplett in deinem Browser.

Gebaut von Dimitri Heissler

Du betreibst gerade etwas Eigenes? Bring deine Website auf schnelles Webhosting.

Webhosting ansehen

Gesucht wird in Nummer, Name, Erklärung, Ursachen und Konfigurationsbeispielen, zum Beispiel nach „timeout“ oder „client_max_body_size“.

Häufig gesucht:

70 von 70 Statuscodes

Bedeutung

Der Server hat die Header der Anfrage erhalten und nichts dagegen einzuwenden. Der Client darf den Body senden. Das gehört zum Header „Expect: 100-continue“, mit dem ein Client vor einem großen Upload nachfragt, ob der Server ihn überhaupt annimmt.

Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server wechselt auf Wunsch des Clients das Protokoll, zum Beispiel von HTTP auf WebSocket. Der Client hat dafür den Header „Upgrade“ geschickt.

Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server bearbeitet die Anfrage noch und hat sie nicht abgeschlossen. Der Code stammt aus WebDAV und verhindert einen Timeout bei langen Operationen. Er gilt als veraltet und kommt kaum noch vor.

Definiert in RFC 2518

Bedeutung

Der Server schickt vorab Hinweise, zum Beispiel „Link“-Header für Stylesheets oder Skripte, während er die eigentliche Antwort noch vorbereitet. Der Browser kann diese Dateien schon laden. Ein Hinweis, kein Fehler.

Definiert in RFC 8297

Bedeutung

Die Anfrage war erfolgreich. Bei GET enthält die Antwort die angeforderte Ressource, bei POST das Ergebnis der Aktion. Es ist der Normalfall, den jede funktionierende Seite liefert.

Für die Suchmaschinen-Optimierung: Ein 200 sagt nur, dass der Server antwortet, nicht, dass der Inhalt stimmt. Eine Fehlerseite, die mit 200 ausgeliefert wird, heißt „Soft 404“ und verwirrt Suchmaschinen.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Die Anfrage war erfolgreich und hat eine neue Ressource angelegt. Typisch bei POST auf eine API. Der Header „Location“ nennt die Adresse der neuen Ressource.

Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server hat die Anfrage angenommen, aber noch nicht fertig bearbeitet. Das Ergebnis liefert er später, zum Beispiel über einen Statusabruf oder einen Webhook. Typisch bei Hintergrundjobs.

Siehe auch:
Definiert in RFC 9110

Bedeutung

Die Anfrage war erfolgreich, die Daten stammen aber nicht direkt vom Ursprungsserver, sondern von einem Proxy, der sie verändert haben kann. Selten zu sehen.

Definiert in RFC 9110

Bedeutung

Die Anfrage war erfolgreich, die Antwort hat bewusst keinen Body. Üblich bei DELETE oder PUT und bei CORS-Preflight-Anfragen (OPTIONS). Wer die Antwort als JSON lesen will, muss den leeren Body abfangen.

Siehe auch:
Definiert in RFC 9110

Bedeutung

Die Anfrage war erfolgreich. Der Client soll die Ansicht zurücksetzen, zum Beispiel ein Formular leeren. Die Antwort hat keinen Body. Wird kaum genutzt.

Definiert in RFC 9110

Bedeutung

Der Server liefert nur den angeforderten Teil einer Datei, weil der Client einen „Range“-Header geschickt hat. Genutzt für Video-Streaming, pausierte Downloads und große Dateien.

Siehe auch:
Definiert in RFC 9110

Bedeutung

Die Antwort enthält mehrere Statuscodes für mehrere Teiloperationen, als XML. Stammt aus WebDAV und taucht bei Kalender-, Kontakt- und Dateisynchronisation auf.

Definiert in RFC 4918

Bedeutung

Die Mitglieder einer WebDAV-Bindung wurden schon in einem früheren Teil derselben Antwort aufgeführt und werden nicht noch einmal aufgelistet. Sehr selten.

Definiert in RFC 5842

Bedeutung

Der Server hat die Anfrage mit einem Delta-Encoding beantwortet: Die Antwort ist das Ergebnis einer oder mehrerer Instanz-Manipulationen auf die aktuelle Ressource. In der Praxis ungenutzt.

Definiert in RFC 3229

Bedeutung

Für die Anfrage gibt es mehrere mögliche Antworten, etwa dieselbe Datei in mehreren Formaten oder Sprachen. Der Client oder Nutzer soll eine auswählen. In der Praxis kaum genutzt.

Siehe auch:
Definiert in RFC 9110

Bedeutung

Dauerhafte Weiterleitung: Die Ressource hat eine neue Adresse, sie steht im Header „Location“. Browser und Suchmaschinen sollen künftig nur noch die neue URL verwenden.

Typische Ursachen

  • Domain- oder URL-Umzug, etwa von http auf https oder von www auf die Hauptdomain
  • Eine Seite wurde umbenannt oder verschoben
  • Eine Weiterleitungsregel in nginx, Apache oder im CMS greift

So behebst du es

  • Verlinke die Ziel-URL direkt, damit die Weiterleitung gar nicht nötig ist.
  • Kürze Weiterleitungsketten (A, B, C) auf einen einzigen Schritt.
  • Bei einer Schleife (ERR_TOO_MANY_REDIRECTS) prüfe die Regeln für http/https und www gegeneinander, oft widersprechen sich Server und CMS.
  • Browser speichern 301 sehr lange. Teste Änderungen im Inkognito-Fenster oder mit curl -I.

Konfiguration und Befehle (Beispiele)

nginx
return 301 https://example.com$request_uri;
Apache
Redirect 301 /alte-seite https://example.com/neue-seite
Für die Suchmaschinen-Optimierung: Ein 301 gibt die Ranking-Signale der alten URL an die neue weiter. Nutze ihn bei jedem dauerhaften Umzug und vermeide Weiterleitungsketten.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Temporäre Weiterleitung: Die Ressource ist vorübergehend unter einer anderen Adresse erreichbar. Der Client soll für diese Anfrage dem Header „Location“ folgen, aber künftig weiter die ursprüngliche URL verwenden. Manche Clients machen dabei aus einem POST ein GET.

Typische Ursachen

  • Zeitlich begrenzte Umleitung, zum Beispiel für eine Kampagne oder Wartung
  • Login-Umleitung auf eine Anmeldeseite
  • Sprach- oder Länderumleitung
  • Fälschlich gesetzt, obwohl der Umzug dauerhaft ist

So behebst du es

  • Melde dauerhafte Umzüge mit 301 oder 308, sonst behalten Suchmaschinen die alte URL.
  • Soll die Methode erhalten bleiben, nimm 307 (temporär) oder 308 (dauerhaft).

Konfiguration und Befehle (Beispiele)

nginx
return 302 https://example.com/sommer-angebot;
Apache
Redirect 302 /angebot https://example.com/sommer-angebot
Für die Suchmaschinen-Optimierung: Bei einem 302 bleibt die alte URL im Index, solange die Umleitung als vorübergehend gilt. Setzt du ihn für einen dauerhaften Umzug, wandern die Rankings nur zögerlich.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Weiterleitung mit GET: Der Client soll das Ergebnis unter einer anderen URL per GET abrufen. Typisch nach einem POST (Post/Redirect/Get), damit ein Neuladen der Seite das Formular nicht erneut absendet.

Siehe auch:
Definiert in RFC 9110

Bedeutung

Die Ressource hat sich seit der letzten Anfrage nicht geändert. Der Server schickt keinen Body, der Browser nimmt die Kopie aus dem Cache. Er hat dazu „If-None-Match“ (ETag) oder „If-Modified-Since“ mitgeschickt. Das spart Bandbreite und beschleunigt die Seite.

Siehe auch:
Definiert in RFC 9110

Bedeutung

Temporäre Weiterleitung wie 302, aber die HTTP-Methode und der Body bleiben beim Folgen der Weiterleitung unverändert: Ein POST bleibt ein POST.

Typische Ursachen

  • Chrome zeigt für HSTS-Umleitungen von http auf https „307 Internal Redirect“ in den Entwicklertools, ohne dass der Server etwas gesendet hat
  • Ein Server leitet eine API-Anfrage vorübergehend um und will die Methode erhalten

So behebst du es

  • Ist die Umleitung dauerhaft, nimm 308 statt 307.

Konfiguration und Befehle (Beispiele)

nginx
return 307 https://example.com$request_uri;
Apache
Redirect 307 /alt https://example.com/neu
Siehe auch:
Definiert in RFC 9110

Bedeutung

Dauerhafte Weiterleitung wie 301, aber die HTTP-Methode und der Body bleiben unverändert: Ein POST bleibt ein POST. Geeignet für dauerhafte API-Umzüge und für Formulare, die ihre Daten nicht verlieren dürfen.

Konfiguration und Befehle (Beispiele)

nginx
return 308 https://example.com$request_uri;
Apache
Redirect 308 /alt https://example.com/neu
Für die Suchmaschinen-Optimierung: Für Suchmaschinen verhält sich 308 wie 301 und überträgt die Rankings auf die neue Adresse.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server versteht die Anfrage nicht, weil sie fehlerhaft aufgebaut ist: ungültige Syntax, kaputte Header oder ein zu großes Cookie. Aus Sicht des Servers liegt der Fehler beim Client.

Typische Ursachen

  • Ungültige Zeichen oder eine falsch kodierte URL, zum Beispiel ein Leerzeichen oder ein % ohne zwei Hexadezimalziffern
  • Zu große oder beschädigte Cookies, bei nginx dann als „Request Header Or Cookie Too Large“
  • Ungültiger JSON-Body oder fehlende Pflichtfelder bei einer API
  • Falsche Host- oder Content-Length-Header, oft durch einen Proxy

So behebst du es

  • Lösche die Cookies der Domain im Browser und lade die Seite neu.
  • Prüfe die URL und kodiere Sonderzeichen, zum Beispiel mit dem URL Encoder.
  • Vergleiche den Request-Body mit der API-Dokumentation.
  • Bei zu großen Headern: Vergrößere die Puffer des Servers.

Konfiguration und Befehle (Beispiele)

nginx
large_client_header_buffers 4 16k;
Siehe auch:
Definiert in RFC 9110

Bedeutung

Die Anfrage braucht eine gültige Authentifizierung. Der Client hat sich nicht angemeldet oder seine Zugangsdaten sind ungültig. Der Server schickt den Header „WWW-Authenticate“ mit, der die erwartete Methode nennt. Der Name ist irreführend: Gemeint ist „nicht authentifiziert“, nicht „nicht berechtigt“ (das ist 403).

Typische Ursachen

  • Kein oder abgelaufenes Token, Passwort oder API-Key
  • Falscher Authorization-Header, zum Beispiel fehlendes „Bearer“ vor dem Token
  • HTTP-Basic-Schutz (.htpasswd) auf der Seite oder dem Verzeichnis

So behebst du es

  • Prüfe Zugangsdaten und die Ablaufzeit des Tokens.
  • Prüfe das Format des Authorization-Headers.
  • Bei Basic Auth: Prüfe den Benutzer in der .htpasswd und den Pfad der Datei in der Konfiguration.

Konfiguration und Befehle (Beispiele)

nginx
auth_basic "Geschützter Bereich";
auth_basic_user_file /etc/nginx/.htpasswd;
Apache
AuthType Basic
AuthName "Geschützter Bereich"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
Siehe auch:
Definiert in RFC 9110

Bedeutung

Reserviert für künftige Bezahlsysteme und nie standardisiert. Einige Dienste nutzen es trotzdem, etwa wenn ein Abo abgelaufen ist oder ein API-Kontingent bezahlt werden muss.

So behebst du es

  • Prüfe den Rechnungs- oder Abo-Status beim Anbieter.
  • Lies die API-Dokumentation des Dienstes, dort ist die Bedeutung festgelegt.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server versteht die Anfrage, verweigert sie aber. Anders als bei 401 hilft eine neue Anmeldung meist nicht: Der Zugriff ist für diese Identität oder diese Adresse nicht erlaubt.

Typische Ursachen

  • Dateirechte oder Besitzer stimmen nicht, der Webserver-Nutzer darf die Datei nicht lesen
  • Im Verzeichnis fehlt ein Index-Dokument und die Verzeichnisauflistung ist abgeschaltet
  • IP-Sperre, Firewall- oder WAF-Regel oder Geoblocking
  • Eine Regel in .htaccess oder der nginx-Konfiguration verbietet den Zugriff (deny all, Require all denied)
  • Ein Sicherheitsmodul wie ModSecurity oder Fail2ban blockiert die Anfrage

So behebst du es

  • Prüfe die Rechte: Verzeichnisse meist 755, Dateien 644, Besitzer passend zum Webserver-Nutzer. Der CHMOD-Rechner rechnet die Zahlen um.
  • Lege eine Index-Datei an (index.html, index.php) oder setze die index-Direktive.
  • Lies das Fehlerlog des Webservers, dort steht der genaue Grund, zum Beispiel „directory index of … is forbidden“.
  • Prüfe IP-Sperren und WAF-Regeln.

Konfiguration und Befehle (Beispiele)

Shell
namei -l /var/www/html/index.html
nginx
index index.html index.php;
Apache
<Directory /var/www/html>
    Require all granted
</Directory>
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server ist erreichbar, kennt die angeforderte Adresse aber nicht. Die Ressource wurde nicht gefunden. Der Server sagt nicht, ob sie nie existierte oder nur gerade fehlt.

Typische Ursachen

  • Tippfehler oder veralteter Link
  • Seite gelöscht, verschoben oder umbenannt, ohne Weiterleitung
  • Falscher Dokumentenpfad im Webserver (root oder alias) oder falsche Groß- und Kleinschreibung, denn Linux unterscheidet sie
  • Fehlende Rewrite-Regeln, zum Beispiel für WordPress-Permalinks oder eine Single-Page-App
  • Die Datei wurde beim Deployment nicht hochgeladen

So behebst du es

  • Prüfe Pfad und Dateiname, auch die Groß- und Kleinschreibung.
  • Setze bei nginx try_files, damit Permalinks und Single-Page-Apps funktionieren: try_files $uri $uri/ /index.php?$args; bzw. /index.html.
  • Leite umgezogene Seiten per 301 auf die neue Adresse.
  • Richte eine eigene 404-Seite mit Suche und Links ein.

Konfiguration und Befehle (Beispiele)

nginx
error_page 404 /404.html;
Apache
ErrorDocument 404 /404.html
Für die Suchmaschinen-Optimierung: Einzelne 404-Seiten schaden dem Ranking nicht. Wichtig sind Seiten mit Backlinks oder Traffic: Leite sie per 301 weiter. Eine Fehlerseite, die mit 200 ausgeliefert wird („Soft 404“), solltest du vermeiden.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Die Ressource gibt es, aber nicht für diese HTTP-Methode (GET, POST, PUT, DELETE und so weiter). Die Antwort muss einen „Allow“-Header mit den erlaubten Methoden enthalten.

Typische Ursachen

  • POST auf eine Route, die nur GET kennt, oder umgekehrt
  • nginx beantwortet ein POST auf eine statische Datei mit 405
  • Eine Weiterleitung mit 301 oder 302 hat das POST in ein GET verwandelt
  • Webserver oder WAF sperren Methoden wie PUT und DELETE

So behebst du es

  • Lies den Header „Allow“, dort stehen die erlaubten Methoden.
  • Prüfe Route und Controller in der Anwendung.
  • Nutze 307 oder 308 statt 301 oder 302, wenn die Methode bei der Weiterleitung erhalten bleiben soll.
  • Sprich direkt die endgültige https-Adresse an, damit keine Weiterleitung die Methode verändert.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server kann keine Antwort in einem Format liefern, das der Client über „Accept“-Header zulässt, etwa Medientyp, Sprache oder Zeichensatz. Außerdem blockieren manche Web Application Firewalls (ModSecurity) Anfragen mit diesem Code.

Typische Ursachen

  • Der Accept-Header fordert zum Beispiel nur application/xml, der Server liefert nur JSON
  • Eine ModSecurity-Regel hat die Anfrage als verdächtig eingestuft, häufig bei Skripten ohne User-Agent

So behebst du es

  • Passe den Accept-Header an, oder lass ihn weg.
  • Lies bei ModSecurity das Audit-Log und prüfe die auslösende Regel.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Wie 401, aber die Anmeldung verlangt ein Proxy-Server, nicht der Zielserver. Der Proxy sendet dazu den Header „Proxy-Authenticate“.

Typische Ursachen

  • Ein Unternehmens- oder Schul-Proxy verlangt einen Login
  • Falsche Proxy-Zugangsdaten in der Systemeinstellung oder bei curl

So behebst du es

  • Trage die Proxy-Zugangsdaten ein, zum Beispiel bei curl mit -x benutzer:passwort@proxy:port.
  • Frag die IT-Abteilung oder den Proxy-Anbieter nach den richtigen Zugangsdaten.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server hat zu lange auf die vollständige Anfrage des Clients gewartet und die Verbindung geschlossen.

Typische Ursachen

  • Langsame oder instabile Verbindung des Clients
  • Ein großer Upload bricht ab
  • Ein Proxy oder Load Balancer hält Verbindungen zu kurz offen
  • Der Browser hat vorab eine Verbindung geöffnet, aber nie benutzt

So behebst du es

  • Prüfe die Verbindung und wiederhole die Anfrage.
  • Erhöhe die Timeouts auf dem Server.
  • Bei Uploads: Verkleinere die Dateien oder lade sie in Teilen hoch.

Konfiguration und Befehle (Beispiele)

nginx
client_header_timeout 60s;
client_body_timeout 60s;
Apache
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
Siehe auch:
Definiert in RFC 9110

Bedeutung

Die Anfrage kollidiert mit dem aktuellen Zustand der Ressource, etwa bei gleichzeitigen Änderungen oder einem Eintrag, der schon existiert. Der Client kann den Konflikt beheben und es erneut versuchen.

Typische Ursachen

  • Ein eindeutiger Wert existiert bereits, zum Beispiel eine E-Mail-Adresse, ein Benutzername oder ein Domainname
  • Zwei Nutzer ändern dieselbe Ressource, die Version passt nicht mehr
  • Die Ressource lässt sich im aktuellen Zustand nicht ändern oder löschen

So behebst du es

  • Lade den aktuellen Zustand neu und wende deine Änderung erneut an.
  • Lies den Antwort-Body: Gute APIs nennen den Konflikt dort genau.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Die Ressource war einmal vorhanden, wurde absichtlich entfernt und kommt nicht wieder. Anders als 404 sagt der Server damit dauerhaft: weg.

Typische Ursachen

  • Der Inhalt wurde bewusst gelöscht, zum Beispiel ein abgelaufenes Angebot
  • Eine Serverregel gibt für alte URLs 410 aus

So behebst du es

  • Gibt es einen Nachfolger, leite per 301 weiter.
  • Beantworte gelöschte URLs, die nie wiederkommen, bewusst mit 410.

Konfiguration und Befehle (Beispiele)

nginx
location = /alte-seite {
    return 410;
}
Apache
Redirect gone /alte-seite
Für die Suchmaschinen-Optimierung: Mit 410 zeigst du Suchmaschinen klar, dass die Seite absichtlich entfernt wurde. Google behandelt 404 und 410 aber ähnlich, der Unterschied ist klein.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server verlangt den Header „Content-Length“, der in der Anfrage fehlt. Er akzeptiert den Body nur mit bekannter Länge.

Typische Ursachen

  • Ein Client schickt den Body in Teilen (chunked) an einen Server, der das nicht annimmt
  • Ein Skript oder Proxy lässt den Header weg

So behebst du es

  • Setze Content-Length oder nimm einen HTTP-Client, der den Header automatisch sendet.
  • Prüfe die Einstellungen des Proxys für das Puffern von Anfragen.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Eine Bedingung im Anfrage-Header (If-Match, If-Unmodified-Since und so weiter) ist nicht erfüllt. Der Server führt die Änderung deshalb nicht aus. So werden überschriebene Änderungen verhindert.

Typische Ursachen

  • Die Ressource hat sich geändert, seit der Client den ETag geladen hat
  • Veralteter ETag in If-Match

So behebst du es

  • Lade die Ressource neu, nimm den frischen ETag und sende die Änderung erneut.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Body der Anfrage ist größer, als der Server annimmt. Typisch bei Datei-Uploads. Der Code hieß früher „Payload Too Large“ und davor „Request Entity Too Large“.

Typische Ursachen

  • nginx: client_max_body_size ist standardmäßig nur 1 MB
  • Apache: LimitRequestBody ist gesetzt
  • PHP: upload_max_filesize oder post_max_size sind zu klein
  • Ein vorgeschaltetes CDN oder ein Proxy begrenzt die Größe

So behebst du es

  • Hebe das Limit in der Konfiguration an und lade den Server neu (nginx -s reload).
  • Erhöhe in der php.ini upload_max_filesize und post_max_size. post_max_size muss mindestens so groß sein wie upload_max_filesize.
  • Prüfe jede Stufe der Kette: CDN, Proxy, Webserver und PHP. Das kleinste Limit gewinnt.

Konfiguration und Befehle (Beispiele)

nginx
client_max_body_size 50M;
Apache
LimitRequestBody 52428800
Siehe auch:
Definiert in RFC 9110

Bedeutung

Die URL ist länger, als der Server verarbeitet. Es steckt meist ein Fehler in der Anwendung dahinter und keine echte Adresse.

Typische Ursachen

  • Sehr viele Parameter in einer GET-Anfrage
  • Eine Weiterleitungsschleife hängt bei jedem Durchlauf weitere Parameter an
  • Große Datenmengen werden per URL statt per POST übertragen

So behebst du es

  • Sende große Daten per POST.
  • Beseitige die Weiterleitungsschleife.
  • Erhöhe bei Bedarf das Limit des Servers.

Konfiguration und Befehle (Beispiele)

nginx
large_client_header_buffers 4 16k;
Apache
LimitRequestLine 16384
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server kennt das Format des gesendeten Bodys nicht (Header „Content-Type“). Er verarbeitet zum Beispiel nur JSON, bekommt aber Formulardaten.

Typische Ursachen

  • Der Content-Type-Header fehlt oder ist falsch, zum Beispiel application/json statt text/plain
  • Der Server erwartet multipart/form-data für Uploads

So behebst du es

  • Setze den Content-Type passend zum Body.
  • Lies die API-Dokumentation.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der angeforderte Bereich (Header „Range“) liegt außerhalb der Datei. Der Server nennt in „Content-Range“ die tatsächliche Größe.

Typische Ursachen

  • Ein Download wird mit einem Offset fortgesetzt, aber die Datei hat sich verkleinert oder wurde ersetzt
  • Ein fehlerhafter Download-Manager

So behebst du es

  • Lösche den Teil-Download und beginne neu.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server kann die Erwartung aus dem Header „Expect“ nicht erfüllen. Meist ist das „100-continue“, das ein Proxy oder Server nicht unterstützt.

Typische Ursachen

  • Ein alter Proxy oder Server ohne Expect-Unterstützung
  • curl schickt bei großen POST-Anfragen automatisch Expect: 100-continue

So behebst du es

  • Schalte den Header bei curl mit -H 'Expect:' ab.
  • Aktualisiere den Proxy.

Konfiguration und Befehle (Beispiele)

Shell
curl -H 'Expect:' -d @datei.json https://example.com/api
Siehe auch:
Definiert in RFC 9110

Bedeutung

Ein Aprilscherz aus RFC 2324 (Hyper Text Coffee Pot Control Protocol): Ein Teekessel lehnt es ab, Kaffee zu brühen. Der Code ist reserviert und wird in der Praxis als Scherz oder zur Abwehr von Bots verwendet.

Definiert in RFC 2324

Bedeutung

Die Anfrage wurde an einen Server geschickt, der für diese Kombination aus Schema und Host keine Antwort liefern kann. Tritt bei HTTP/2 auf, wenn ein Browser eine Verbindung für mehrere Hostnamen wiederverwendet.

Typische Ursachen

  • Mehrere Domains auf einer IP mit gemeinsamem Zertifikat, aber unterschiedlicher Konfiguration je Host
  • SNI und Host-Header passen nicht zusammen

So behebst du es

  • Vereinheitliche Zertifikate und virtuelle Hosts der betroffenen Domains.
  • Prüfe mit curl --resolve, welcher Host antwortet.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server versteht die Anfrage und das Format stimmt, aber der Inhalt ist fachlich ungültig, zum Beispiel fehlt ein Pflichtfeld oder ein Wert liegt außerhalb des erlaubten Bereichs. Der Code hieß früher „Unprocessable Entity“. Viele Frameworks nutzen ihn für Validierungsfehler.

Typische Ursachen

  • Die Validierung schlägt fehl, zum Beispiel bei E-Mail-Format, Länge oder Pflichtfeld
  • Ein logischer Fehler, etwa ein Enddatum vor dem Startdatum

So behebst du es

  • Lies den Antwort-Body, dort stehen Felder und Fehlermeldungen.
  • Prüfe die Eingaben gegen die API-Dokumentation.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Die Ressource ist gesperrt, zum Beispiel weil sie jemand in WebDAV zum Bearbeiten ausgecheckt hat.

So behebst du es

  • Hebe die Sperre auf (UNLOCK) oder warte, bis der andere Nutzer fertig ist.
Siehe auch:
Definiert in RFC 4918

Bedeutung

Die Anfrage ist gescheitert, weil eine andere Anfrage, von der sie abhängt, gescheitert ist. Stammt aus WebDAV und wird auch von Orchestrierungs-Werkzeugen genutzt.

Siehe auch:
Definiert in RFC 4918

Bedeutung

Der Server will eine Anfrage nicht verarbeiten, die erneut abgespielt werden könnte (Replay-Angriff). Tritt bei TLS 1.3 Early Data (0-RTT) auf.

Definiert in RFC 8470

Bedeutung

Der Server verlangt ein anderes Protokoll. Der Header „Upgrade“ nennt es. Ein Beispiel ist eine Anfrage über HTTP/1.1, obwohl der Server TLS oder HTTP/2 verlangt.

Typische Ursachen

  • Veraltete TLS-Version
  • Die API ist nur über WebSocket oder HTTPS erreichbar

So behebst du es

  • Aktualisiere Client und Bibliothek.
  • Sende die Anfrage über das geforderte Protokoll.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server verlangt eine Bedingung (If-Match), damit nicht versehentlich eine veraltete Version überschrieben wird.

Typische Ursachen

  • Ein PUT ohne If-Match auf eine geschützte Ressource

So behebst du es

  • Hole den ETag der Ressource und setze ihn im Header If-Match.
Siehe auch:
Definiert in RFC 6585

Bedeutung

Der Client hat in einer bestimmten Zeit zu viele Anfragen gesendet (Rate Limiting). Der Header „Retry-After“ nennt, wann er es erneut versuchen darf.

Typische Ursachen

  • API- oder Login-Limit überschritten, zum Beispiel durch eine Schleife im Skript
  • Ein Bot, Crawler oder Scraper erzeugt viel Last
  • Ein Brute-Force-Schutz (Fail2ban, WAF) greift
  • Mehrere Nutzer teilen sich eine IP-Adresse (NAT, VPN) und zählen zusammen

So behebst du es

  • Warte die Zeit aus Retry-After ab und wiederhole mit wachsendem Abstand (Exponential Backoff).
  • Bündle Anfragen und speichere Antworten zwischen.
  • Als Betreiber: Setze Limits pro IP oder API-Key und antworte mit 429, nginx nutzt standardmäßig 503.
  • Lass legitime Crawler zu.

Konfiguration und Befehle (Beispiele)

nginx
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}
Für die Suchmaschinen-Optimierung: Der Googlebot behandelt 429 wie einen Serverfehler und crawlt langsamer. Setze Limits so, dass Suchmaschinen nicht dauerhaft getroffen werden.
Siehe auch:
Definiert in RFC 6585

Bedeutung

Die Header der Anfrage sind insgesamt oder einzeln zu groß. Der häufigste Auslöser sind zu viele oder zu große Cookies.

Typische Ursachen

  • Angesammelte Cookies (Tracking, Sessions) auf einer Domain
  • Ein sehr langer Authorization-Header, zum Beispiel ein großes JWT
  • Eine Weiterleitungsschleife hängt immer weitere Cookies an

So behebst du es

  • Lösche die Cookies der Domain.
  • Vergrößere die Header-Puffer des Servers.
  • Halte JWTs und Header klein.

Konfiguration und Befehle (Beispiele)

nginx
large_client_header_buffers 4 16k;
Apache
LimitRequestFieldSize 16384
Siehe auch:
Definiert in RFC 6585

Bedeutung

Ein nginx-spezifischer Code, der nie an den Client gesendet wird: nginx schließt die Verbindung ohne Antwort. Er steht nur im Access-Log. Betreiber setzen ihn mit return 444; ein, um Bots und ungültige Host-Anfragen abzuweisen.

Typische Ursachen

  • return 444; in der nginx-Konfiguration, zum Beispiel im Default-Server

So behebst du es

  • Ist es gewollt, musst du nichts tun.
  • Ist es ungewollt, prüfe die Regel mit nginx -T und suche nach return 444.

Konfiguration und Befehle (Beispiele)

nginx
server {
    listen 80 default_server;
    return 444;
}
Siehe auch:
Definiert in nginx

Bedeutung

Die Ressource ist aus rechtlichen Gründen gesperrt, etwa wegen eines Gerichtsbeschlusses, Zensur oder Geoblocking. Der Code spielt auf Ray Bradburys Roman „Fahrenheit 451“ an.

Typische Ursachen

  • Sperre auf Anordnung, zum Beispiel wegen Urheberrecht oder einer Behörde
  • Der Anbieter blockiert bestimmte Regionen wegen rechtlicher Auflagen

So behebst du es

  • Der Betreiber nennt den Grund meist im Body der Antwort.
  • Frag den Betreiber, eine Umgehung der Sperre kann rechtswidrig sein.
Siehe auch:
Definiert in RFC 7725

Bedeutung

Der Client hat die Verbindung geschlossen, bevor nginx die Antwort senden konnte. Der Code steht nur im nginx-Log, es ist kein echter HTTP-Code.

Typische Ursachen

  • Ein Nutzer bricht den Seitenaufbau ab oder schließt den Tab
  • Das Timeout des Clients ist kürzer als die Antwortzeit des Servers
  • Ein Load Balancer oder Proxy davor bricht zu früh ab

So behebst du es

  • Senke die Antwortzeit der Anwendung, etwa bei langsamen Datenbankabfragen.
  • Stimme die Timeouts von Client, Proxy und Server aufeinander ab.
Siehe auch:
Definiert in nginx

Bedeutung

Ein allgemeiner Serverfehler: Der Server ist auf ein unerwartetes Problem gestoßen und konnte die Anfrage nicht erfüllen. Der Code verrät nicht, was schiefging, die Ursache steht im Fehlerlog.

Typische Ursachen

  • Fehler im Anwendungscode, zum Beispiel ein PHP-Fatal-Error oder eine nicht abgefangene Exception
  • Fehlerhafte .htaccess oder fehlerhafte Webserver-Konfiguration
  • Falsche Dateirechte oder ein falscher Besitzer auf Skripten
  • Die Datenbank ist nicht erreichbar oder die Zugangsdaten stimmen nicht
  • Das PHP-Speicherlimit (memory_limit) oder max_execution_time ist erreicht
  • Eine PHP-Erweiterung fehlt oder die PHP-Version passt nicht zum Plugin

So behebst du es

  • Lies das Fehlerlog: Dort stehen Datei und Zeile des Fehlers.
  • Nimm Änderungen der letzten Minuten zurück (Plugin, Update, .htaccess).
  • Teste die Konfiguration mit nginx -t bzw. apachectl configtest.
  • Aktiviere den Debug-Modus (WP_DEBUG, APP_DEBUG) nur lokal oder kurz, nie dauerhaft auf einem Produktivsystem.

Konfiguration und Befehle (Beispiele)

nginx
tail -n 50 /var/log/nginx/error.log
Apache
tail -n 50 /var/log/apache2/error.log
Für die Suchmaschinen-Optimierung: Der Googlebot kommt bei dauerhaften 5xx-Fehlern seltener. Hält ein Fehler Tage an, können URLs aus dem Index fallen.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server kennt die angeforderte Methode nicht oder kann sie nicht umsetzen. Anders als bei 405 geht es nicht um diese eine Ressource, sondern um fehlende Unterstützung insgesamt.

Typische Ursachen

  • Eine ungewöhnliche oder falsch geschriebene HTTP-Methode
  • Server oder Proxy unterstützen die Funktion nicht, zum Beispiel bei alter Software

So behebst du es

  • Prüfe die verwendete Methode.
  • Aktualisiere die Server-Software.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Ein Server, der als Gateway oder Proxy arbeitet (nginx, Apache, Load Balancer, CDN), hat von dem Server dahinter eine ungültige oder gar keine Antwort bekommen. Der Fehler liegt zwischen den Servern, nicht beim Besucher.

Typische Ursachen

  • Der Backend-Dienst (PHP-FPM, Node.js, Gunicorn, Docker-Container) läuft nicht oder ist abgestürzt
  • Falscher Upstream: Port oder Socket in proxy_pass bzw. fastcgi_pass stimmen nicht
  • Das Backend schließt die Verbindung vorzeitig, zum Beispiel bei Speicherproblemen oder einem Absturz
  • Eine Firewall oder SELinux blockiert die Verbindung zum Backend
  • Ein CDN erreicht den Ursprungsserver nicht richtig

So behebst du es

  • Prüfe den Status des Backend-Dienstes und starte ihn neu (systemctl status, docker ps).
  • Prüfe, ob unter der Upstream-Adresse etwas lauscht (ss -tlnp).
  • Lies das Fehlerlog des Webservers: „connect() failed (111: Connection refused) while connecting to upstream“ nennt das Ziel.
  • Prüfe Socket-Pfad und Berechtigungen von PHP-FPM.
  • Reicht der Arbeitsspeicher? Der OOM-Killer beendet oft zuerst den Backend-Prozess.

Konfiguration und Befehle (Beispiele)

Shell
ss -tlnp | grep :3000
nginx
tail -n 50 /var/log/nginx/error.log
Shell
dmesg | grep -i "out of memory"
Für die Suchmaschinen-Optimierung: Ein kurzer 502 stört Suchmaschinen kaum. Dauert er an, behandelt der Googlebot die Seite wie bei jedem anderen 5xx-Fehler und crawlt weniger.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server ist vorübergehend nicht in der Lage, die Anfrage zu bearbeiten, meist wegen Überlastung oder Wartung. Er kann mit „Retry-After“ mitteilen, wann es wieder klappt.

Typische Ursachen

  • Wartungsmodus, zum Beispiel von WordPress oder Laravel, oder eine geplante Wartung
  • Überlast: zu viele gleichzeitige Anfragen oder Prozesse, zum Beispiel ist pm.max_children bei PHP-FPM erreicht
  • Ein Backend-Dienst hinter Proxy oder Load Balancer ist nicht erreichbar
  • nginx beantwortet Überschreitungen von limit_req und limit_conn standardmäßig mit 503
  • Ressourcenlimits des Hostings (CPU, RAM, Prozesse) sind erreicht

So behebst du es

  • Beende den Wartungsmodus. Prüfe auf eine .maintenance-Datei (WordPress) oder auf php artisan down (Laravel).
  • Sieh dir die Auslastung an (top, free -m) und erhöhe Prozess-Limits wie pm.max_children.
  • Liefere bei geplanter Wartung bewusst 503 mit Retry-After aus.
  • Prüfe das Webserver-Log auf Upstream-Fehler.

Konfiguration und Befehle (Beispiele)

nginx
error_page 503 /wartung.html;

location / {
    return 503;
}

location = /wartung.html {
    root /var/www/wartung;
    internal;
    add_header Retry-After 3600 always;
}
Apache
ErrorDocument 503 /wartung.html
Header always set Retry-After "3600"

RewriteEngine On
RewriteCond %{REQUEST_URI} !=/wartung.html
RewriteRule ^ - [R=503,L]
Für die Suchmaschinen-Optimierung: Ein kurzes 503 mit Retry-After ist für Suchmaschinen der richtige Weg bei Wartung. Dauert es Tage, können die URLs aus dem Index fallen.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Das Gateway oder der Proxy hat vom Server dahinter nicht rechtzeitig eine Antwort bekommen. Anders als bei 502 ist die Antwort nicht ungültig, sondern zu langsam.

Typische Ursachen

  • Eine langsame Anwendung: schwere Datenbankabfrage, Report, Import oder externer API-Aufruf
  • Das Backend ist überlastet, alle PHP-FPM-Worker sind belegt
  • Die Timeout-Werte des Proxys sind niedriger als die Laufzeit der Anfrage
  • Ein Netzwerkproblem zwischen Proxy und Backend

So behebst du es

  • Finde langsame Abfragen und Skripte und beschleunige sie (Slow Query Log, Profiler).
  • Lagere lange Aufgaben in Hintergrundjobs aus.
  • Hebe die Timeouts abgestimmt an: proxy_read_timeout, fastcgi_read_timeout und max_execution_time in PHP.
  • Prüfe die Kapazität des Backends (Worker, Arbeitsspeicher).

Konfiguration und Befehle (Beispiele)

nginx
proxy_read_timeout 120s;
fastcgi_read_timeout 120s;
Apache
ProxyTimeout 120
Siehe auch:
Definiert in RFC 9110

Bedeutung

Der Server unterstützt die in der Anfrage genutzte HTTP-Version nicht.

Typische Ursachen

  • Ein sehr alter oder fehlerhafter Client oder Proxy nutzt eine unübliche HTTP-Version
  • Das Zielsystem spricht nur eine bestimmte Version

So behebst du es

  • Aktualisiere den Client oder erzwinge HTTP/1.1, bei curl mit --http1.1.
Siehe auch:
Definiert in RFC 9110

Bedeutung

Die Server-Konfiguration für Content Negotiation ist fehlerhaft: Die gewählte Variante verweist selbst wieder auf eine Aushandlung. Praktisch nur bei Fehlkonfigurationen zu sehen.

Siehe auch:
Definiert in RFC 2295

Bedeutung

Der Server hat nicht genug Speicherplatz, um die Anfrage abzuschließen.

Typische Ursachen

  • Festplatte, Quota oder Inodes sind voll
  • Der Upload lässt sich nicht mehr speichern

So behebst du es

  • Prüfe den Speicher mit df -h und df -i und räume alte Logs, Backups und Caches auf.
  • Erhöhe das Kontingent.

Konfiguration und Befehle (Beispiele)

Shell
df -h && df -i
Siehe auch:
Definiert in RFC 4918

Bedeutung

Der Server hat bei der Bearbeitung eine Endlosschleife erkannt.

Typische Ursachen

  • Eine zirkuläre WebDAV-Bindung
  • Eine Verzeichnisstruktur mit Symlink-Schleife

So behebst du es

  • Prüfe Bindungen und Symlinks.
Siehe auch:
Definiert in RFC 5842

Bedeutung

Die Anfrage enthält nicht die Erweiterung, die der Server nach RFC 2774 verlangt. Der Code ist historisch und praktisch nie zu sehen.

Definiert in RFC 2774

Bedeutung

Der Client muss sich im Netzwerk anmelden, bevor er Zugang bekommt. Gesendet von einem Captive Portal, etwa im WLAN von Hotel, Flughafen oder Café.

Typische Ursachen

  • Ein Captive Portal im WLAN verlangt Login oder Zustimmung

So behebst du es

  • Rufe eine beliebige Seite über http auf, zum Beispiel http://neverssl.com, damit das Portal erscheint.
  • Melde dich im Portal an.
Siehe auch:
Definiert in RFC 6585

Bedeutung

Cloudflare hat vom Ursprungsserver eine Antwort bekommen, die es nicht verarbeiten kann: leer, abgebrochen oder mit ungültigen Headern. Ein Sammelfehler von Cloudflare.

Typische Ursachen

  • Der Ursprungsserver stürzt bei der Anfrage ab, zum Beispiel durch einen PHP-Fehler
  • Die Antwort-Header sind größer als 32 KB, oft durch zu viele Cookies
  • Die Antwort ist leer oder die Verbindung wurde ohne Antwort geschlossen
  • Eine Firewall blockiert Cloudflare-IP-Adressen teilweise

So behebst du es

  • Lies das Fehlerlog des Ursprungsservers.
  • Gib die Cloudflare-IP-Bereiche in Firewall und Fail2ban frei.
  • Verkleinere Header und Cookies.
Siehe auch:
Definiert in Cloudflare

Bedeutung

Cloudflare konnte keine Verbindung zum Ursprungsserver aufbauen: Er hat die Verbindung abgelehnt. Seite und Cloudflare sind erreichbar, nur dein Server dahinter nicht.

Typische Ursachen

  • Der Webserver (nginx, Apache) läuft nicht
  • Eine Firewall oder der Hoster blockiert die Cloudflare-IP-Adressen
  • Falsche Ursprungs-IP oder falscher Port in der Cloudflare-Einstellung

So behebst du es

  • Starte den Webserver und prüfe, ob er auf Port 80 und 443 lauscht.
  • Gib die Cloudflare-IP-Bereiche frei.
  • Prüfe den DNS-A-Eintrag und den Ursprungs-Port.

Konfiguration und Befehle (Beispiele)

Shell
ss -tlnp | grep -E ':(80|443)\b'
Siehe auch:
Definiert in Cloudflare

Bedeutung

Cloudflare wollte sich mit dem Ursprungsserver verbinden, aber der TCP-Handshake kam nicht rechtzeitig zustande. Es ist ein Timeout beim Verbindungsaufbau, noch bevor eine Anfrage gesendet wird.

Typische Ursachen

  • Der Ursprungsserver ist überlastet oder offline
  • Eine Firewall verwirft Pakete von Cloudflare
  • Falsche IP-Adresse oder ein Routing-Problem

So behebst du es

  • Prüfe Erreichbarkeit und Auslastung des Servers.
  • Gib die Cloudflare-IP-Bereiche in der Firewall frei.
  • Prüfe die IP-Adresse im DNS-Eintrag.
Siehe auch:
Definiert in Cloudflare

Bedeutung

Cloudflare kann den Ursprungsserver nicht erreichen, zum Beispiel wegen eines DNS-Fehlers oder einer fehlenden Route.

Typische Ursachen

  • Falsche IP-Adresse im DNS-Eintrag
  • Server oder Rechenzentrum offline, Routing-Problem

So behebst du es

  • Prüfe den DNS-Eintrag.
  • Frag den Hoster und prüfe das Netzwerk.
Siehe auch:
Definiert in Cloudflare

Bedeutung

Cloudflare konnte sich verbinden, aber der Ursprungsserver hat nicht innerhalb von 100 Sekunden eine HTTP-Antwort geliefert.

Typische Ursachen

  • Lange Skripte, Exporte oder Importe
  • Ein überlasteter Server

So behebst du es

  • Lagere lange Aufgaben in Hintergrundjobs aus.
  • Senke die Antwortzeit.
  • Nutze für lange Aufgaben Streaming oder Statusabfragen statt einer einzigen Anfrage.
Siehe auch:
Definiert in Cloudflare

Bedeutung

Der TLS-Handshake zwischen Cloudflare und dem Ursprungsserver ist fehlgeschlagen.

Typische Ursachen

  • Der Ursprungsserver bietet kein HTTPS auf Port 443 an
  • Es gibt keine gemeinsame Cipher-Suite oder TLS-Version
  • SNI fehlt oder das Zertifikat passt nicht

So behebst du es

  • Prüfe die TLS-Konfiguration des Ursprungsservers.
  • Wähle den SSL/TLS-Modus in Cloudflare passend zum Ursprungsserver.
Siehe auch:
Definiert in Cloudflare

Bedeutung

Cloudflare konnte das Zertifikat des Ursprungsservers nicht prüfen. Tritt im Modus „Full (strict)“ auf.

Typische Ursachen

  • Abgelaufenes, selbst signiertes oder nicht für die Domain ausgestelltes Zertifikat
  • Ein Zwischenzertifikat fehlt

So behebst du es

  • Installiere ein gültiges Zertifikat (Let's Encrypt oder ein Cloudflare Origin Certificate).
  • Liefere die vollständige Zertifikatskette aus.
Siehe auch:
Definiert in Cloudflare

Beispiel-Ergebnis

Was dir die HTTP-Status-Codes-Referenz zeigt

Du gibst eine Nummer oder ein Stichwort ein und bekommst sofort die passenden Statuscodes, jeweils mit Bedeutung, typischen Ursachen, Lösung und, wo es passt, einem fertigen Beispiel für nginx oder Apache. Drei Beispiele:

Beispiel 1: Eine Nummer nachschlagen

Eingabe:

502

Ausgabe: ein Eintrag mit diesen Angaben

Statuscode und Name
502 Bad Gateway
Klasse
5xx Server-Fehler
Bedeutung
Ein Server, der als Gateway oder Proxy arbeitet (nginx, Apache, Load Balancer, CDN), hat von dem Server dahinter eine ungültige oder gar keine Antwort bekommen. Der Fehler liegt zwischen den Servern, nicht beim Besucher.
Erste typische Ursache
Der Backend-Dienst (PHP-FPM, Node.js, Gunicorn, Docker-Container) läuft nicht oder ist abgestürzt
Erster Lösungsschritt
Prüfe den Status des Backend-Dienstes und starte ihn neu (systemctl status, docker ps).
Beispiel zum Kopieren (nginx)
tail -n 50 /var/log/nginx/error.log

Ergebnis in Worten: Bei 502 Bad Gateway antwortet der Server hinter dem Proxy nicht oder ungültig. Der Eintrag nennt 5 typische Ursachen und 5 Lösungsschritte, zum Beispiel den Backend-Dienst zu prüfen und das Fehlerlog zu lesen. Der Fehler liegt zwischen den Servern, nicht beim Besucher.

Beispiel 2: Nach einer Klasse suchen

Eingabe:

3xx

Ausgabe: alle Codes der Klasse 3xx aus der Liste

Treffer der Suche nach 3xx
StatuscodeName
300Multiple Choices
301Moved Permanently
302Found
303See Other
304Not Modified
307Temporary Redirect
308Permanent Redirect

Ergebnis in Worten: Die Liste enthält 7 Codes der Klasse 3xx, die veralteten 305 und 306 fehlen. Nicht jeder davon leitet weiter, 304 etwa verweist auf den Cache. Die wichtigsten sind 301 (dauerhaft umgezogen), 302 (vorübergehend umgeleitet) und 304 (unverändert, Cache nutzen). Jeder Eintrag erklärt, wann er auftritt und wie du ihn richtig einsetzt.

Beispiel 3: Nach einem Stichwort suchen

Eingabe:

timeout

Ausgabe: die besten Treffer zuerst

  1. 408 Request Timeout
  2. 504 Gateway Timeout
  3. 524 A Timeout Occurred
  4. 102 Processing
  5. 522 Connection Timed Out

Ergebnis in Worten: 6 Einträge enthalten das Stichwort. Treffer im Namen stehen oben: 408 Request Timeout, 504 Gateway Timeout, 524 A Timeout Occurred. Danach folgen Einträge, in denen „timeout“ nur in Erklärung, Ursachen oder Konfigurationsbeispielen vorkommt.

So funktioniert es

So schlägst du einen Statuscode nach

Vier Schritte von der Nummer bis zum fertigen Beispiel – ohne Account, ohne Download.

Schritt 1

Statuscode oder Stichwort eingeben

Tippe eine Nummer wie 502, einen Namen wie „bad gateway“ oder ein Stichwort wie „timeout“ oder „Weiterleitung“ in das Suchfeld. Die Treffer erscheinen bei jedem Zeichen sofort.

Schritt 2

Nach Klasse filtern

Mit den Filtern grenzt du auf eine Klasse ein: 3xx für Weiterleitungen, 4xx für Client-Fehler, 5xx für Server-Fehler. „Häufig gesucht“ zeigt die Codes, auf die du im Alltag triffst.

Schritt 3

Eintrag aufklappen

Ein Klick auf einen Code zeigt die Bedeutung und, je nach Code, typische Ursachen, Lösungsschritte und den Effekt auf die Suchmaschinen-Optimierung. „Siehe auch“ springt zu verwandten Codes.

Schritt 4

Beispiel kopieren und anpassen

Wo es hilft, steht ein Beispiel für nginx, Apache oder die Shell dabei. Kopiere es, passe Pfade und Werte an deinen Server an und lade den Webserver neu.

Häufige Fehler

404, 403, 500, 502, 503: die häufigsten HTTP-Fehler kurz erklärt

Kurzantwort zu jedem Fehlercode. Mit „Alle Ursachen und Lösung“ öffnest du den vollständigen Eintrag in der Referenz oben.

400

Bad Request

Der Server versteht die Anfrage nicht. Häufige Gründe sind eine fehlerhafte Adresse, zu große oder beschädigte Cookies und ein ungültiger Request-Header. Lösche die Cookies der Seite und prüfe die Adresse.

Alle Ursachen und Lösung

401

Unauthorized

Für die Seite ist eine Anmeldung nötig und deine fehlt oder ist ungültig. Mit korrekten Zugangsdaten klappt es, zum Beispiel beim Passwortschutz per .htaccess oder bei einer API mit Token.

Alle Ursachen und Lösung

403

Forbidden

Der Server kennt die Adresse, verweigert dir aber den Zugriff. Häufige Ursachen sind falsche Dateirechte, ein fehlendes Index-Dokument, eine IP-Sperre oder eine Firewall-Regel.

Alle Ursachen und Lösung

404

Not Found

Unter dieser Adresse gibt es nichts: Tippfehler, gelöschte oder umgezogene Seite, oder die Groß- und Kleinschreibung stimmt nicht. Umgezogene Seiten leitest du per 301 weiter. Einzelne 404-Fehler schaden dem Ranking nicht.

Alle Ursachen und Lösung

429

Too Many Requests

Du hast in kurzer Zeit zu viele Anfragen gesendet. Warte die Zeit aus dem Header Retry-After ab und versuche es dann erneut, mit wachsendem Abstand.

Alle Ursachen und Lösung

500

Internal Server Error

Ein allgemeiner Fehler auf dem Server. Die Ursache steht im Fehlerlog des Webservers. Oft stecken ein Codefehler, eine defekte .htaccess, falsche Rechte oder eine nicht erreichbare Datenbank dahinter.

Alle Ursachen und Lösung

502

Bad Gateway

Der Proxy oder Load Balancer bekommt vom Backend keine gültige Antwort, meist weil PHP-FPM, Node.js oder der Anwendungsserver nicht läuft oder abgestürzt ist. Prüfe den Dienst und sein Log.

Alle Ursachen und Lösung

503

Service Unavailable

Der Server ist überlastet oder in Wartung und sagt, dass es nur vorübergehend ist. Für Wartungsarbeiten ist 503 mit dem Header Retry-After der richtige Code.

Alle Ursachen und Lösung

504

Gateway Timeout

Das Backend antwortet zu langsam, der Proxy gibt nach seiner Wartezeit auf. Suche langsame Abfragen oder Skripte und erhöhe bei Bedarf das Timeout, bei nginx proxy_read_timeout.

Alle Ursachen und Lösung

Überblick

Die fünf Klassen der HTTP-Antwortcodes

Die erste Ziffer verrät, worum es geht. Daran erkennst du auch ohne Nachschlagen, ob der Fehler beim Besucher oder beim Server liegt.

1xx

Informationen

Die Anfrage ist angekommen und wird weiter bearbeitet. Eine Zwischenmeldung, noch kein Ergebnis.

Häufig:

4 Codes in dieser Referenz

2xx

Erfolg

Die Anfrage wurde verstanden und erfolgreich bearbeitet. 200 ist der Normalfall.

Häufig: 200, 201, 204

10 Codes in dieser Referenz

3xx

Weiterleitung

Der Client muss einen weiteren Schritt gehen, meist einer neuen Adresse folgen oder den Cache nutzen.

Häufig: 301, 302, 304, 307, 308

7 Codes in dieser Referenz

4xx

Client-Fehler

Die Anfrage ist fehlerhaft oder nicht erlaubt. Aus Sicht des Servers liegt der Fehler beim Client, etwa 404 bei einer unbekannten Adresse.

Häufig: 400, 401, 403, 404, 405, 410, 413, 422, 429

31 Codes in dieser Referenz

5xx

Server-Fehler

Die Anfrage war in Ordnung, aber der Server hat sie nicht erfüllt. Hier liegt der Fehler beim Betreiber, etwa 500, 502 oder 503.

Häufig: 500, 502, 503, 504

18 Codes in dieser Referenz

Weiterleitungen

301 oder 302? Die Weiterleitungs-Codes im Vergleich

Fünf Codes leiten weiter. Sie unterscheiden sich in zwei Punkten: ob die Umleitung dauerhaft ist und ob der Client die HTTP-Methode behält.

Vergleich der Weiterleitungs-Statuscodes 301, 302, 303, 307 und 308
StatuscodeDauerMethode bleibt
301 Moved PermanentlyUmzug einer Seite oder Domain, http auf https, www auf die Hauptdomain. Der Standard für SEO.dauerhaftnicht garantiert
302 FoundZeitlich begrenzte Umleitung, zum Beispiel Kampagnen, Login oder Sprachwahl.vorübergehendnicht garantiert
303 See OtherNach einem POST auf eine Ergebnisseite weiterleiten (Post/Redirect/Get). Der Browser ruft sie per GET ab.vorübergehendnicht garantiert
307 Temporary RedirectVorübergehende Umleitung einer API oder eines Formulars, bei der die Methode erhalten bleiben muss.vorübergehendja
308 Permanent RedirectDauerhafter Umzug einer API oder eines Formular-Ziels, bei dem die Methode erhalten bleiben muss.dauerhaftja

Faustregel: 301 für normale Seiten, die dauerhaft umziehen, 302 für Zeitweiliges. Soll bei einer API oder einem Formular das POST erhalten bleiben, nimm 308 statt 301 und 307 statt 302. „Nicht garantiert“ heißt: Browser machen aus einem POST häufig ein GET.

Praxis

So findest du den Statuscode einer Seite

Im Browser öffnest du die Entwicklertools (F12) und im Tab „Netzwerk“ siehst du den Code jeder Anfrage. Auf dem Server oder in der Shell helfen diese vier Befehle:

Zeigt nur die Antwort-Header, die erste Zeile enthält den Statuscode.

curl -I https://example.com/seite

Gibt ausschließlich den Statuscode aus, praktisch für Skripte und Monitoring.

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/seite

Folgt Weiterleitungen und zeigt jede Station mit Statuscode und Ziel.

curl -sIL https://example.com/alt | grep -iE '^(HTTP|location)'

Zählt die Statuscodes im Access-Log von nginx oder Apache (Format combined) und sortiert sie nach Häufigkeit.

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

Mehr entdecken

Weitere Tools

Website Down Checker

Prüfen, ob eine Website online, langsam oder offline ist: HTTP-Status, Antwortzeit und die Ursache bei Fehlern wie DNS-Problem, Timeout, TLS-Fehler oder 5xx.

Gebaut von Eric Mager

SSL Checker

Status, Aussteller, Gültigkeitszeitraum und Ablaufdatum eines SSL/TLS-Zertifikats auf einen Blick prüfen.

Gebaut von Sebastian Rademacher

Redirect Checker

Weiterleitungsketten einer URL Hop für Hop prüfen: Statuscodes (301/302/307/308), HTTP-Header, Server-IP und Antwortzeit je Weiterleitung.

Gebaut von Luca Stanek

Port Checker

Prüfen, ob bestimmte Ports auf einer IP oder einem Hostname offen sind — Protokoll oder Spiel auswählen statt alle Ports auf einmal zu scannen.

Gebaut von Sebastian Rademacher

CHMOD-Rechner

Unix-/Linux-Dateiberechtigungen per Checkbox zu Oktalwert und symbolischer Notation zusammenstellen oder umgekehrt dekodieren - inklusive setuid/setgid/Sticky-Bit und fertigem chmod-Befehl zum Kopieren.

Gebaut von Justin Schuessler

.htaccess Generator & htpasswd Generator

Apache-.htaccess und .htpasswd online erstellen: 301-Weiterleitungen, HTTPS, Passwortschutz mit bcrypt, WordPress-Regeln, Fehlerseiten, Caching, GZIP und Hotlink-Schutz. Läuft komplett im Browser.

Gebaut von Dimitri Heissler

FAQ

Häufig gestellte Fragen

Kurze Antworten zu den häufigsten HTTP-Codes, ihren Ursachen und dieser Referenz.

Ein HTTP-Statuscode ist eine dreistellige Zahl, die ein Server auf jede Anfrage zurückgibt. Sie sagt, ob die Anfrage geklappt hat und wenn nicht, warum. Die erste Ziffer nennt die Klasse: 1xx Information, 2xx Erfolg, 3xx Weiterleitung, 4xx Fehler beim Client, 5xx Fehler beim Server. Die HTTP-Fehlercodes, auf die du am häufigsten triffst, sind 400, 401, 403, 404 und 429 beim Client sowie 500, 502, 503 und 504 beim Server. Der Filter „Häufig gesucht“ in der Referenz zeigt sie zusammen mit weiteren Codes, die im Alltag oft vorkommen.

200 OK heißt, dass die Anfrage geklappt hat und der Server die Seite oder die Daten mitliefert. Es ist der Normalfall für jede Seite, die Besucher und Suchmaschinen sehen sollen. Achte darauf, dass Fehlerseiten nicht mit 200 ausgeliefert werden, sonst entstehen „Soft 404“. Verwandte Codes: 201 Created meldet eine neu angelegte Ressource, 204 No Content eine erfolgreiche Antwort ohne Body, und 304 Not Modified heißt, dass sich die Datei nicht geändert hat und der Browser seine Kopie nutzt.

Der Server versteht die Anfrage nicht und lehnt sie ab, bevor er sie bearbeitet. Typische Ursachen sind eine fehlerhafte Adresse mit ungültigen Zeichen, zu große oder beschädigte Cookies, ein zu großer Header und ein falsch formatierter Request-Body bei einer API. Als Besucher löschst du die Cookies der Seite. Als Betreiber prüfst du Anfrage, Header und Log. Stimmt das Format, ist aber ein Wert ungültig, etwa ein fehlendes Pflichtfeld, antworten viele APIs stattdessen mit 422 Unprocessable Content (früher „Unprocessable Entity“).

Der Server ist erreichbar, kennt die Adresse aber nicht. Prüfe zuerst Tippfehler und die Groß- und Kleinschreibung der Datei, denn Linux unterscheidet sie. Danach den Pfad im Webserver und, bei WordPress oder einer Single-Page-App, die Rewrite-Regeln (bei nginx try_files). Umgezogene Seiten leitest du per 301 weiter. Einzelne 404 schaden dem Ranking nicht, wohl aber wichtige Seiten mit Backlinks, die ins Leere laufen.

401 Unauthorized heißt „nicht angemeldet“: Mit gültigen Zugangsdaten klappt es. 403 Forbidden heißt „angemeldet oder nicht, aber nicht erlaubt“: Der Server verweigert den Zugriff trotzdem. Häufige Ursachen für 403 sind falsche Dateirechte oder Besitzer, ein fehlendes Index-Dokument, IP-Sperren und WAF-Regeln. Der CHMOD-Rechner rechnet Rechte wie 755 für Verzeichnisse und 644 für Dateien um. Zum CHMOD-Rechner

Der Code verrät die Ursache nicht, sie steht im Fehlerlog des Webservers (bei nginx /var/log/nginx/error.log, bei Apache /var/log/apache2/error.log) oder im PHP-Log. Häufige Auslöser sind ein Fehler im Code, eine fehlerhafte .htaccess, falsche Dateirechte, nicht erreichbare Datenbank oder ein erschöpftes PHP-Speicherlimit. Nimm die letzte Änderung (Plugin, Update, Regel) zurück und teste die Konfiguration mit nginx -t oder apachectl configtest.

502 Bad Gateway: Der Proxy bekommt vom Backend eine ungültige oder gar keine Antwort, meist weil der Dienst (PHP-FPM, Node.js) nicht läuft. 503 Service Unavailable: Der Server ist überlastet oder in Wartung und sagt das selbst. 504 Gateway Timeout: Das Backend antwortet, aber zu langsam, meist wegen einer schweren Abfrage oder Überlast. Erste Hilfe bei allen dreien: Fehlerlog lesen und den Backend-Dienst prüfen. Für geplante Wartung ist 503 mit dem Header „Retry-After“ der richtige Code, nicht eine Wartungsseite mit 200.

301 meldet einen dauerhaften Umzug: Suchmaschinen übernehmen die neue Adresse und geben die Rankings weiter. 302 meldet eine vorübergehende Umleitung: Die alte Adresse bleibt im Index. Nimm 301 für Domain- und Seitenumzüge und 302 für Zeitweiliges wie Kampagnen. Soll bei einem Formular oder einer API die Methode (POST) erhalten bleiben, nutzt du 308 statt 301 und 307 statt 302.

Das sind keine Codes aus dem HTTP-Standard. 520 bis 526 kommen von Cloudflare und sagen, dass Cloudflare, nicht dein Besucher, ein Problem mit deinem Ursprungsserver hat: 520 unbekannter Fehler, 521 Verbindung abgelehnt, 522 Verbindung kam nicht zustande, 523 Ursprungsserver nicht erreichbar, 524 keine Antwort innerhalb von 100 Sekunden, 525 TLS-Handshake fehlgeschlagen, 526 ungültiges Zertifikat. Meist hilft es, die Cloudflare-IP-Bereiche in der Firewall freizugeben und Webserver und Zertifikat zu prüfen. 444 und 499 stehen nur im nginx-Log: Bei 444 schließt nginx die Verbindung bewusst ohne Antwort, bei 499 hat der Client die Verbindung geschlossen, bevor die Antwort kam.

Im Browser öffnest du mit F12 die Entwicklertools und schaust im Tab „Netzwerk“ in die Spalte „Status“. In der Shell zeigt curl -I https://example.com die Header samt Statuscode, und curl -s -o /dev/null -w "%{http_code}" https://example.com gibt nur die Zahl aus. Mit curl -sIL siehst du auch jede Weiterleitung auf dem Weg. Diese Referenz selbst ruft keine Adressen ab: Sie läuft komplett in deinem Browser, nur Suchbegriff und Klassenfilter stehen in der Adresszeile, damit du eine Suche teilen kannst. Eine Weiterleitungskette prüfst du mit dem Redirect Checker. Zum Redirect Checker

Noch weitere Fragen?

Support kontaktieren
Du betreibst gerade etwas Eigenes?

Statuscode 200 statt 502: Hosting, das deine Anwendung zuverlässig ausliefert

Ein ZAP-Hosting vServer bringt deine Anwendung oder dein Projekt zuverlässig online.

4,4/5 Trustpilot32.000+ Aktive ServerSeit 2010
Hosting ansehen

Kein Setup. Kein Risiko. In Sekunden online.

Flexible LaufzeitJederzeit kündbarIn 60 Sekunden online

Auf der Suche nach weiteren Tools? Alle Entwickler-Tools ansehen