HTTP- und Serverfehler

Über diese Fehlerkategorie

# HTTP- und Serverfehler

HTTP- und Serverfehler treten auf, wenn eine Anfrage nicht normal abgeschlossen werden kann. Einige Fehler liefern einen HTTP-Statuscode wie 500, 502, 503 oder 504 zurück. Andere treten auf, bevor der Browser eine HTTP-Antwort erhält, und erzeugen Meldungen wie ERR_CONNECTION_REFUSED oder ERR_CONNECTION_TIMED_OUT.

Die Browsermeldung beschreibt das Symptom, aber nicht immer die Komponente, die untersucht werden muss. Ermitteln Sie zunächst, an welcher Grenze der Fehler auftritt: zwischen Browser und Netzwerk, Netzwerk und auf dem Port lauschendem Dienst, Proxy und Backend oder Anwendung und Abhängigkeit.

Zuerst den Fehlertyp bestimmen

Ein HTTP-Statuscode wurde zurückgegeben

Ein numerischer Status bedeutet, dass eine HTTP-fähige Komponente geantwortet hat. Dabei kann es sich um den Origin-Webserver, einen Reverse Proxy, Load Balancer oder ein CDN handeln – nicht unbedingt um die Anwendung selbst.

• 500 Internal Server Error: Der Server ist bei der Verarbeitung der Anfrage auf einen unerwarteten Zustand gestoßen. Beginnen Sie mit den Logs der Anwendung und des Webservers. Siehe den [Leitfaden zu 500 Internal Server Error](/http-500-internal-server-error).
• 502 Bad Gateway: Ein Proxy hat von seinem Backend eine ungültige, leere oder nicht nutzbare Antwort erhalten. Prüfen Sie den Backend-Prozess, den Upstream-Host und -Port sowie die Verbindung zwischen Proxy und Origin. Siehe den [Leitfaden zu 502 Bad Gateway](/http-502-bad-gateway).
• 503 Service Unavailable: Der Dienst kann die Anfrage zu diesem Zeitpunkt nicht verarbeiten. Mögliche Ursachen sind ein Wartungsmodus, erschöpfte Kapazitäten, ein nicht verfügbarer Prozess oder eine ausgefallene Abhängigkeit. Siehe den [Leitfaden zu 503 Service Unavailable](/http-503-service-unavailable).
• 504 Gateway Timeout: Ein Gateway hat die Anfrage weitergeleitet, aber vor Ablauf seines Timeouts keine Antwort erhalten. Das Backend läuft möglicherweise noch, ist aber langsam oder überlastet beziehungsweise wartet auf einen anderen Dienst. Siehe den [Leitfaden zu 504 Gateway Timeout](/http-504-gateway-timeout).

Ein Statuscode allein beweist nicht, in welcher Schicht der Fehler aufgetreten ist. Prüfen Sie Branding, Header und Zeitstempel der Antwort sowie die Logs, um festzustellen, ob die Antwort vom Origin oder von einem Vermittler stammt.

Der Browser meldet einen Verbindungsfehler

Ein Fehler auf Verbindungsebene bedeutet, dass der Browser vom erwarteten Endpunkt keine normale HTTP-Antwort erhalten hat.

• ERR_CONNECTION_REFUSED: Das Ziel wurde erreicht, aber die Verbindung wurde abgelehnt. Prüfen Sie, ob ein Dienst am erwarteten Port lauscht und ob lokale oder netzwerkbezogene Sicherheitsregeln den Zugriff beeinflussen. Für Entwicklungsumgebungen siehe [ERR_CONNECTION_REFUSED auf localhost](/err-connection-refused-localhost).
• ERR_CONNECTION_TIMED_OUT: Der Browser hat gewartet, ohne eine nutzbare Antwort zu erhalten. Untersuchen Sie Netzwerkpfad, Routing, Filterung, DNS, Erreichbarkeit des Servers und verfügbare Ressourcen, bevor Sie nach einem von der Anwendung erzeugten HTTP-Fehler suchen. Siehe den [Leitfaden zu ERR_CONNECTION_TIMED_OUT](/err-connection-timed-out).

Eine praktische Diagnoseabfolge

1. Den Fehler reproduzieren und dokumentieren

Laden Sie die Seite einmal neu und rufen Sie dieselbe URL anschließend in einem privaten Fenster oder auf einem anderen Gerät auf. Notieren Sie die genaue URL, den Fehlertext, den Statuscode, den ungefähren Zeitpunkt und die sichtbare Antwortseite. Eine gebrandete CDN- oder Proxy-Seite deutet darauf hin, dass die Anfrage einen Vermittler erreicht hat; eine allgemeine Browsermeldung kann bedeuten, dass keine nutzbare HTTP-Antwort eingetroffen ist.

Wenn der Fehler nur in einem Browser oder auf einem Gerät auftritt, prüfen Sie dessen Proxy, VPN, DNS-Cache, Erweiterungen und lokale Sicherheitssoftware. Wenn dieselbe URL auf mehreren Geräten und in mehreren Netzwerken fehlschlägt, sind der Server, Proxy, Origin oder ein gemeinsamer Netzwerkpfad wahrscheinlicher die Ursache.

2. Den betroffenen Bereich bestimmen

Stellen Sie fest, ob das Problem nur eine Route, einen Host, eine gesamte Anwendung oder den kompletten Dienst betrifft.

• Ein Fehler bei nur einer Route kann auf Anwendungscode, eine routenspezifische Abhängigkeit oder eine langsame Abfrage hindeuten.
• Wenn jede Route 500 zurückgibt, spricht das für ein umfassenderes Problem mit der Anwendung oder der Serverkonfiguration.
• Ein 502 oder 504 über einen Proxy lenkt die Aufmerksamkeit auf den Origin-Prozess, die Upstream-Verbindung oder die Proxy-Konfiguration.
• Eine abgelehnte Verbindung an einem Port kann bedeuten, dass der erwartete Dienst nicht lauscht, während andere Dienste weiterhin verfügbar sind.

Vergleichen Sie nach Möglichkeit einen funktionierenden Endpunkt mit dem fehlerhaften. Unterschiede bei Routing, Authentifizierung, Abhängigkeiten und Deployment-Status sind oft aussagekräftiger als Änderungen an nicht zusammenhängenden Client-Einstellungen.

3. Die Komponente prüfen, die die Antwort erzeugt hat

Ordnen Sie bei einem 500 die Logs der Anwendung und des Webservers dem Zeitpunkt des Fehlers zu. Bei 502-, 503- und 504-Antworten sollten Sie sowohl die Logs von Proxy oder Gateway als auch die Backend-Logs prüfen. Achten Sie auf einen gestoppten Prozess, ein fehlgeschlagenes Deployment, einen Fehler bei der Verbindung zu einer Abhängigkeit, erschöpfte Ressourcen oder eine Anfrage, die ein relevantes Timeout überschreitet.

Bei einem lokalen ERR_CONNECTION_REFUSED prüfen Sie, ob Apache oder Nginx läuft und ob der konfigurierte Port verfügbar ist. XAMPP, Laragon und MAMP können dieses Symptom zeigen, wenn ihr Webserver nicht gestartet wurde oder ein anderes Programm verhindert, dass er den erwarteten Port bindet.

4. Origin und Abhängigkeiten separat testen

Wenn Sie den Dienst verwalten, prüfen Sie, ob das Backend Verbindungen annimmt und auf einen einfachen Endpunkt antwortet. Gehen Sie dabei nicht davon aus, dass eine erfolgreiche Proxy-Verbindung beweist, dass die Anwendung fehlerfrei läuft. Prüfen Sie anschließend die benötigten Dienste wie die Datenbank oder andere konfigurierte Abhängigkeiten.

Ein Backend, das erreichbar, aber dauerhaft langsam ist, passt eher zu einem 504 als ein Backend, das gestoppt ist oder eine nicht nutzbare Antwort liefert, was einen 502 verursachen kann. Ein 503 kann auftreten, bevor eine Anfrage die Anwendung erreicht, wenn der Dienst absichtlich nicht verfügbar ist oder eine benötigte Abhängigkeit nicht verwendet werden kann.

Vermeiden Sie wiederholtes Neuladen als Methode zur Fehlersuche. Dadurch kann zusätzliche Last entstehen, während das zugrunde liegende Prozess-, Abhängigkeits- oder Timeout-Problem untersucht wird.

Fehlerdetails nutzen, um die Schicht zu bestimmen

Antworttext, Header und Zeitstempel können zeigen, welche Komponente den Fehler verarbeitet hat:

• Eine allgemeine Browsermeldung weist meist darauf hin, dass keine nutzbare HTTP-Antwort empfangen wurde.
• Eine gebrandete Proxy- oder CDN-Seite zeigt, dass ein Vermittler den Fehler erzeugt oder angezeigt hat.
• Eine anwendungsspezifische Fehlerseite kann direkter auf die Origin-Anwendung hindeuten.

Bei sporadischen Fehlern sollten Sie den Zeitpunkt mit Deployments, steigendem Traffic, Prozessneustarts und der Latenz von Abhängigkeiten abgleichen. Bei dauerhaft auftretenden Fehlern vergleichen Sie eine funktionierende Anfrage mit der fehlerhaften und prüfen Sie Konfigurationsunterschiede, bevor Sie Servereinstellungen ändern.

Bei Websites, die Cloudflare verwenden, bedeutet ein von Cloudflare gebrandeter 504 im Allgemeinen, dass der Edge innerhalb des geltenden Timeout-Fensters keine Antwort vom Origin erhalten konnte. Der [Leitfaden zu 504 Gateway Timeout hinter Cloudflare](/504-gateway-timeout-cloudflare) erklärt, wie Sie ein Origin-Problem von einem Timeout unterscheiden, das von einem anderen Gateway oder vom Origin selbst erzeugt wurde.

Was Sie bei einer Supportanfrage angeben sollten

Ein hilfreicher Fehlerbericht enthält:

• Den genauen Fehlertext und Statuscode
• Den URL-Pfad und den ungefähren Zeitpunkt des Fehlers
• Die Information, ob andere Benutzer, Geräte oder Netzwerke betroffen sind
• Die Information, ob ein Proxy, CDN oder Load Balancer beteiligt ist
• Relevante Einträge aus Webserver-, Proxy- und Anwendungs-Logs, wobei Passwörter, Tokens und andere Geheimnisse entfernt wurden

Ziel ist es, die fehlerhafte Grenze zu ermitteln. Sobald diese Grenze bekannt ist, kann der passende Fehlerleitfaden gezieltere Prüfungen liefern, ohne Ursachen in Browser, Netzwerk, Proxy und Backend gleichzusetzen.