ERR_EMPTY_RESPONSE: Bedeutung und so behebst du den Fehler

Was ist ERR_EMPTY_RESPONSE?

ERR_EMPTY_RESPONSE ist die Fehlerseite in Chrome und Edge mit dem Text „Diese Seite funktioniert nicht. example.com hat keine Daten gesendet.“ In Chromium ist das der Netzwerkfehler -324, definiert als: „The server closed the connection without sending any data.“ (Der Server hat die Verbindung geschlossen, ohne Daten zu senden.)

Der Browser ist weiter gekommen als bei den meisten Verbindungsfehlern. Die Adresse wurde aufgelöst, die Verbindung stand, und der Browser hat seine Anfrage gesendet. Dann hat der Server oder etwas davor die Verbindung mit einer leeren Antwort geschlossen: kein Statuscode, keine Header, keine Seite. Chromium nutzt diesen Fehler nur für eine frische Verbindung, die sich mit null Bytes schließt. Schließt sich eine alte, wiederverwendete Verbindung, versucht Chrome es stillschweigend erneut.

Weil tatsächlich eine Anfrage zugestellt wurde, deutet ERR_EMPTY_RESPONSE meist auf die Serverseite hin: eine App, die beim Bearbeiten der Anfrage abgestürzt ist, eine Regel, die Verbindungen absichtlich verwirft, oder ein Dienst, der die Verbindung angenommen hat, hinter dem aber nichts lief. Ein paar Ursachen auf deinem eigenen Computer können ihn aber auch auslösen.

Was verursacht ERR_EMPTY_RESPONSE?

Lösung 1: Neu laden und Inkognito testen

Hat der Server im falschen Moment neu gestartet, reicht es, ein paar Sekunden später neu zu laden. Wiederholt sich der Fehler, öffne die Seite in einem Inkognito-Fenster (Strg + Umschalt + N, Mac Cmd + Umschalt + N). Inkognito startet ohne Cookies und ohne Erweiterungen und zeigt dir so schnell, ob etwas in deinem Browser Gespeichertes beteiligt ist.

Prüfe dann, ob die Website für alle ausgefallen ist. Das Tool HTTP-Headers von DNS Robot ruft die Seite von unseren Servern aus ab: Bekommen wir eine normale Antwort, liegt das Problem zwischen dir und der Website. Bekommen auch wir nichts, scheitert die Website selbst.

Lösung 2: VPN, Proxy und HTTPS-Scan ausschalten

Alles, was mitten in deinen Verbindungen sitzt, kann die Anfrage annehmen und die Verbindung dann schließen, ohne die Antwort weiterzureichen:

• VPN: Trenne es vollständig und lade neu.

• Proxy: Unter Windows 11 Einstellungen → Netzwerk und Internet → Proxy → Proxyserver verwenden ausschalten. Auf dem Mac Systemeinstellungen → Netzwerk → deine Verbindung → Details … → Proxies.

• HTTPS-Scan des Antivirus: Schalte nur die Web- bzw. HTTPS-Scan-Funktion aus (oft HTTPS-Scan, Web-Schutz (Web Shield) oder SSL/TLS-Protokollfilterung genannt) und lade neu. Behebt das den Fehler, richte eine Ausnahme für die Website ein und schalte den Scan wieder ein.

Lösung 3: Website-Daten löschen und Erweiterungen deaktivieren

Sehr große oder beschädigte Cookies können einen Server dazu bringen, die Anfrage zu verwerfen, statt zu antworten. Das zeigt sich oft als Fehler, der erst nach dem Einloggen auftritt. Lösche die Cookies dieser Website: Klicke auf das Symbol links in der Adressleiste → Cookies und Websitedaten (oder Website-Einstellungen) → Daten löschen und melde dich erneut an.

Deaktiviere als Nächstes alle Erweiterungen unter chrome://extensions und lade neu. Schalte sie nacheinander wieder ein, um diejenige zu finden, die stört. Oft ist es ein Werbeblocker, ein Datenschutz-Tool oder etwas, das Anfragen bearbeitet.

Lösung 4: DNS-Cache leeren und Netzwerk-Stack zurücksetzen

Liefert auf einem Computer jede Website leere Antworten, setz seine Netzwerkkonfiguration zurück. Führe unter Windows die Befehle unten in einer Eingabeaufforderung als Administrator aus und starte neu. Auf dem Mac leerst du den DNS-Cache, entfernst das WLAN-Netzwerk und fügst es neu hinzu.

ipconfig /flushdns
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew

Probiere auch ein anderes Netzwerk, etwa die mobilen Daten deines Smartphones. Funktioniert die Website dort, kappt womöglich ein Filter in deinem üblichen Netzwerk (Schule, Arbeit oder Internetanbieter) die Verbindung.

ERR_EMPTY_RESPONSE auf localhost und mit Docker

Am häufigsten sehen Entwickler diesen Fehler auf dem eigenen Rechner. Die üblichen Ursachen:

• Die App in einem Docker-Container lauscht auf 127.0.0.1. In einem Container bedeutet 127.0.0.1 „nur dieser Container“. Die Portweiterleitung von Docker hat also nichts, womit sie sich verbinden kann, und dein Browser bekommt eine leere Antwort (oder, je nach Einrichtung, einen Verbindungsreset). Lass die App im Container auf 0.0.0.0 lauschen, zum Beispiel mit next dev -H 0.0.0.0, vite --host 0.0.0.0, flask run --host=0.0.0.0 oder uvicorn main:app --host 0.0.0.0.

• Das Port-Mapping des Containers passt nicht. -p 8080:3000 leitet deinen Port 8080 an Port 3000 im Container weiter. Lauscht die App tatsächlich auf 5000, kommt jede Anfrage leer zurück.

• http:// auf einem reinen HTTPS-Port. Manche Server erwarten auf einem Port TLS und legen einfach auf, wenn unverschlüsseltes HTTP ankommt. Probiere https://localhost:8443 statt http://.

• Der Dev-Server ist beim Bearbeiten der Anfrage abgestürzt. Sieh im Terminal nach, in dem er läuft. Eine Exception oder ein Out-of-Memory-Fehler in genau diesem Moment ist deine Antwort.

# Ohne Browser reproduzieren
curl -v http://localhost:8080/
# "Empty reply from server" = Verbindung angenommen, nichts zurückgesendet

# Welche Ports veröffentlicht der Container, und was lauscht darin?
docker ps --format "table {{.Names}}\t{{.Ports}}"
docker exec -it <container> sh -c "netstat -tlnp 2>/dev/null || ss -tlnp"

Für Website-Betreiber: Warum dein Server leere Antworten sendet

• Abstürze und Out-of-Memory-Kills. Stirbt der Prozess, der die Anfrage bearbeitet, schließt sich die Verbindung, ohne dass etwas gesendet wurde. Prüfe die App-Logs und dmesg -T | grep -i "killed process" auf den Out-of-Memory-Killer von Linux, vor allem bei schweren Seiten und Uploads.

• Absichtliches Verwerfen. Das spezielle return 444; von nginx schließt die Verbindung ohne jede Antwort und wird oft genutzt, um böse Bots oder unbekannte Hostnamen abzuwehren. Trifft eine solche Regel echte Besucher (eine zu breite User-Agent- oder GeoIP-Regel), sehen sie ERR_EMPTY_RESPONSE oder bei HTTP/2-Verbindungen ERR_HTTP2_PROTOCOL_ERROR, weil nginx dort stattdessen den Stream zurücksetzt. WAFs, Rate-Limiter und Bot-Schutzdienste können dasselbe tun.

• Portweiterleitungen und Load Balancer ohne Backend. Ein Listener, der die Verbindung annimmt, hinter dem aber kein funktionierender Server steht, kann sie leer schließen. Prüfe den Zustand der Ziele (Target Health) und ob der Backend-Port stimmt.

• Timeouts, die schließen statt zu antworten. Sorge dafür, dass lange laufende Anfragen einen ordentlichen Fehler liefern (etwa 504), statt den Socket stillschweigend zu schließen, damit Besucher und Monitoring sehen, was passiert ist.

• Zu große Anfragen. Sehr große Header oder Cookies können manche Server dazu bringen, die Anfrage zu verwerfen. Halte Cookies klein.

# Gibt es Regeln, die Verbindungen verwerfen?
sudo grep -rn "return 444" /etc/nginx/

# Von außen testen, so wie Besucher sich verbinden
curl -sv https://yourdomain.com/ -o /dev/null

ERR_EMPTY_RESPONSE vs. ähnliche Fehler

Verwandte Anleitungen: ERR_CONNECTION_CLOSED, ERR_CONNECTION_RESET, 502 Bad Gateway und 500 Internal Server Error. Ob der Port eines Servers Verbindungen von außen annimmt, prüfst du mit dem Port-Checker.