ERR_EMPTY_RESPONSE: Ursachen und Lösungen

2026-09-19

ERR_EMPTY_RESPONSE bedeutet, die Verbindung wurde angenommen, aber der Server hat null Bytes zurückgeschickt, statt einer richtigen HTTP-Antwort oder auch nur einer Fehlerseite. Der TCP-Handshake gelang; was auch immer die Anfrage hätte beantworten sollen, tat es nie.

Was ERR_EMPTY_RESPONSE bedeutet

Dieser Fehler sitzt später im Anfrage-Lebenszyklus als eine abgelehnte oder in eine Zeitüberschreitung gelaufene Verbindung. Der Browser verbindet sich erfolgreich mit dem Server, und bei einer HTTPS-Anfrage schließt normalerweise auch der TLS-Handshake ab, aber nachdem die Anfrage gesendet wurde, schließt die Verbindung ohne HTTP-Statuszeile, ohne Header und ganz ohne Body. Das unterscheidet sich von einer 500- oder 502-Fehlerseite, die immer noch eine vollständige HTTP-Antwort ist; hier gibt es nichts zu parsen, weil nichts zurückkam.

Das macht ERR_EMPTY_RESPONSE clientseitig schwerer zu diagnostizieren als die meisten Verbindungsfehler, da jede Schicht bis einschließlich der Transportverbindung korrekt funktioniert hat. Der Fehler sitzt konkret in dem, was die HTTP-Antwort erzeugen soll: dem Anwendungsprozess, dem Framework, das die Anfrage bearbeitet, oder einem Proxy davor, der den Socket geschlossen hat, statt eine richtige Fehlerseite weiterzugeben oder zu erzeugen.

Wie sich der Fehler zeigt

Chrome zeigt "This site can't be reached ... ERR_EMPTY_RESPONSE", sobald die Verbindung ohne Daten schließt. curl meldet denselben Zustand in klaren Worten:

curl -v https://example.com/api/generate
* Connected to example.com (203.0.113.10) port 443
> GET /api/generate HTTP/1.1
> Host: example.com
*
* Empty reply from server
curl: (52) Empty reply from server

"Empty reply from server" ist curls genauer Wortlaut für diesen Zustand, und es ist das klarste Zeichen dafür, dass die Verbindung selbst funktioniert hat, während das, was eine Antwort hätte erzeugen sollen, es nicht tat.

Was ERR_EMPTY_RESPONSE verursacht

Ein Worker-Prozess ist während der Bearbeitung der Anfrage abgestürzt. Eine unbehandelte Ausnahme, ein Out-of-Memory-Kill, oder ein Speicherzugriffsfehler können die Verbindung schließen, bevor irgendeine Antwort geschrieben wird.
Die Anwendung lief hinter einem Proxy, der still schließt, in eine Zeitüberschreitung. Manche Reverse-Proxy-Konfigurationen schließen die Client-Verbindung ohne Fehlerseite, wenn das Backend zu lange braucht, statt einen richtigen 502 oder 504 zurückzugeben.
Auf dem HTTPS-Port wird einfaches HTTP bedient, oder umgekehrt. Ein Client, der TLS mit einem Port spricht, der einfaches HTTP bedient, oder umgekehrt, bekommt keine gültige Antwort, die seine Protokollschicht parsen kann, und das zeigt sich oft als leere Antwort statt als klarer Protokollfehler.
Eine Browser-Erweiterung oder ein lokaler Proxy stört die Antwort. Ad-Blocker, Privacy-Erweiterungen, oder ein Unternehmens-Proxy, der Antworten untersucht und gelegentlich falsch behandelt, kann sie auf nichts zusammenstreichen.
Ein Health-Check des Load Balancers markiert das Backend mitten in der Anfrage als ungesund und schließt die Verbindung zu diesem Backend, bevor die Antwort fertig ist.

So finden Sie heraus, wer schuld ist

Deaktivieren Sie zuerst Browser-Erweiterungen oder probieren Sie ein Inkognito-Fenster; eine clientseitige Erweiterung ist eine der häufigeren und am leichtesten auszuschließenden Ursachen. Bleibt die leere Antwort auch mit deaktivierten Erweiterungen bestehen, testen Sie von einem zweiten Gerät oder Netzwerk aus, um einen lokalen Proxy auszuschließen. Passiert es konsequent von mehreren externen Standorten aus, ist der Server oder ein Anwendungsabsturz die Ursache. Eine HTTP-Prüfung von mehreren Prüfpunkten gleichzeitig bestätigt, ob die leere Antwort überall auftritt oder an einen Client, eine Erweiterung, oder ein Netzwerk gebunden ist.

So beheben Sie ERR_EMPTY_RESPONSE

Wenn Sie Besucher sind

Probieren Sie ein Inkognito- oder privates Fenster mit deaktivierten Erweiterungen, um einen Ad-Blocker oder eine störende Privacy-Erweiterung auszuschließen.
Deaktivieren Sie jeden lokalen Proxy oder jedes VPN und versuchen Sie es erneut, da manche Antworten abfangen und gelegentlich falsch behandeln, statt sie durchzulassen.
Leeren Sie den Browser-Cache für die Website; ein zwischengespeicherter, beschädigter Verbindungszustand kann gelegentlich als dieser Fehler bei einem erneuten Versuch wieder auftauchen.
Warten Sie und laden Sie neu. Liegt die Ursache in einem abgestürzten Worker-Prozess auf dem Server, startet ein Prozessüberwacher ihn meist innerhalb von Sekunden neu.

Wenn Sie die Website betreiben

Prüfen Sie die Anwendungslogs auf einen Absturz zum selben Zeitstempel wie die fehlgeschlagene Anfrage; eine unbehandelte Ausnahme oder ein Out-of-Memory-Kill ist die häufigste Ursache und hinterlässt meist eine klare Spur.
Bestätigen Sie, dass an jedem Port das richtige Protokoll gebunden ist. Prüfen Sie mit einem direkten Test, ob Port 443 tatsächlich TLS bedient und Port 80 einfaches HTTP, nicht umgekehrt:
```
curl -v https://example.com:443/
curl -v http://example.com:80/
```
Überprüfen Sie das Timeout-Verhalten des Reverse-Proxys. Bei nginx sollte ein Backend, das proxy_read_timeout überschreitet, trotzdem einen 504 zurückgeben; eine leere Antwort statt einer richtigen Fehlerseite bedeutet also meist, dass etwas weiter unten im Stack die Verbindung schließt.
Prüfen Sie Load-Balancer- und Health-Check-Logs auf ein zum Zeitpunkt des Fehlers als ungesund markiertes Backend, was in Bearbeitung befindliche Verbindungen zu dieser Instanz schließen kann.
Starten Sie den betroffenen Worker oder Dienst neu, falls ein Absturz bestätigt ist, und beobachten Sie die Logs nach dem Neustart genau auf eine Wiederholung desselben Fehlers.

So beugen Sie ERR_EMPTY_RESPONSE vor

Ein Worker-Absturz unter bestimmten Bedingungen, etwa einem bestimmten Anfrage-Payload oder einem Speicherspitzenwert, kann unregelmäßig genug sein, um einen manuellen Test zu bestehen, während er für echte Besucher regelmäßig fehlschlägt. Laufendes HTTP-Monitoring, das Statuscode und Antwort-Body regelmäßig von über 300 Prüfpunkten in 158 Städten prüft, erkennt ein Muster leerer Antworten, das ein einzelner manueller Test wahrscheinlich verpassen würde, mit Alarmen per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr.

Häufig gestellte Fragen

Ist ERR_EMPTY_RESPONSE dasselbe wie ein 502-Fehler?

Nein. Ein 502 ist eine vollständige HTTP-Antwort mit Statuszeile, Headern und meist einem Body, absichtlich von einem Proxy gesendet. ERR_EMPTY_RESPONSE bedeutet, es wurde überhaupt keine HTTP-Antwort gesendet, nur eine geschlossene Verbindung.

Warum passiert das nur auf einer bestimmten Seite?

Eine Seite, die diesen Fehler konsequent auslöst, während andere sauber laden, deutet meist auf einen Absturz in dem Code-Pfad hin, den genau diese Seite oder dieser API-Endpunkt nutzt, statt auf ein allgemeines Server- oder Netzwerkproblem.

Kann ein Ad-Blocker diesen Fehler wirklich verursachen?

Ja. Manche Ad-Blocker und Privacy-Erweiterungen fangen Antworten ab und schreiben sie um, und ein Fehler oder eine zu aggressive Regel kann eine legitime Antwort gelegentlich auf nichts zusammenstreichen, statt sie sauber zu blockieren.

Bedeutet ERR_EMPTY_RESPONSE, dass meine Daten verloren sind?

Nicht zwingend bei einer GET-Anfrage, aber bei einem Formular-Absenden oder einem API-Aufruf, der Daten ändert, prüfen Sie, ob die Aktion auf dem Server tatsächlich abgeschlossen wurde, bevor Sie es erneut versuchen, da der Client an einer leeren Antwort nicht erkennen kann, ob die Anfrage verarbeitet wurde.

Warum sagt curl "Empty reply from server" statt eines Fehlercodes?

Weil es keine HTTP-Antwort gibt, aus der ein Statuscode gelesen werden könnte. Curls eigener Wortlaut beschreibt das Ereignis auf Transportebene, eine geschlossene Verbindung ohne Daten, das eine Schicht unter dem HTTP-Protokoll selbst liegt.

Könnte mein eigenes Netzwerk die Verbindung schließen statt der Server?

Das ist seltener als eine serverseitige Ursache, kommt aber vor. Ein Unternehmens-Proxy oder eine Firewall, die lang laufende Verbindungen nach einer festen Leerlaufzeit beendet, kann dasselbe Symptom erzeugen; dieselbe Anfrage von einem anderen Netzwerk aus zu testen schließt das schnell aus.