ERR_EMPTY_RESPONSE

Was dieser Fehler bedeutet und wie du ihn erkennst

• Der Browser zeigt ERR_EMPTY_RESPONSE anstelle eines HTTP-Status wie 200, 404 oder 500.
• Die Anfrage schlägt fehl, bevor der Browser Response-Header, HTML oder eine Fehlerseite der Anwendung empfängt.
• Ein erneutes Laden kann gelegentlich erfolgreich sein, wenn sich ein Worker, ein Connection Pool oder ein Upstream-Dienst erholt.
• Ein Hostname oder eine Route kann fehlschlagen, während andere Websites weiterhin erreichbar sind.
• Eine ausführliche Anfrage über die Kommandozeile kann zeigen, dass die TCP-Verbindung geöffnet und anschließend ohne Response-Header geschlossen wird.
• Die öffentliche URL kann über einen Reverse-Proxy fehlschlagen, während sich eine autorisierte Anfrage an den Upstream-Dienst anders verhält.
• Der Fehler kann nur einen Browser, ein Gerät, ein Quellnetzwerk, ein VPN oder einen Proxy-Pfad betreffen.

Hauptursachen nach Wahrscheinlichkeit

1. Die Anwendung oder der PHP-FPM-Worker wurde beendet, bevor eine Response gesendet wurde. Fatale Anwendungsfehler, Worker-Abstürze, Prozesslimits, Speicherdruck oder fehlgeschlagene Abhängigkeiten können die Anfrage beenden, bevor eine normale HTTP-Response erzeugt wird.
2. Nginx oder der Host hat die Verbindungs- oder File-Descriptor-Kapazität erreicht. Die effektive Einstellung worker_connections, Open-File-Limits, aktive Verbindungen und verfügbarer Speicher beeinflussen, ob Anfragen und Upstream-Verbindungen abgeschlossen werden können.
3. Ein Reverse-Proxy kann keine gültige Upstream-Verbindung aufrechterhalten. Inkompatibles Keepalive-Verhalten, die Wiederverwendung von Verbindungen, Timeout-Werte oder Proxy-Einstellungen können dazu führen, dass die Client-Verbindung geschlossen wird, bevor Upstream-Header eintreffen.
4. Der Upstream-Dienst ist nicht verfügbar oder setzt Verbindungen zurück. Ein Dienst kann zwar laufen, aber nicht in der Lage sein, die Anfrage anzunehmen, zu verarbeiten oder abzuschließen.
5. Eine Firewall, ein VPN, ein WAF, ein Load Balancer oder ein anderes Netzwerkgerät schließt die Verbindung. Das ist wahrscheinlicher, wenn der Fehler vom Client-Netzwerk, der Quelladresse oder dem Routing abhängt.
6. Eine lokale Bedingung im Browser beeinflusst die Anfrage. Erweiterungen, zwischengespeicherter Verbindungsstatus, ein lokaler Proxy, ein VPN oder Sicherheitssoftware können ein ähnliches Symptom verursachen, wenn andere Clients normal funktionieren.

So behebst du den Fehler

1. Fehlerumfang bestimmen

Notieren Sie den Hostnamen, den exakten Pfad, die ungefähre Uhrzeit mit Zeitzone, den Client, das Netzwerk und ob der Fehler dauerhaft auftritt. Testen Sie denselben Pfad in einem privaten Fenster, einem anderen Browser, auf einem anderen Gerät und – sofern zulässig – in einem anderen Netzwerk.

Wenn nur ein Browser oder Gerät betroffen ist, untersuchen Sie zunächst Erweiterungen, lokale Proxy-Einstellungen, VPN-Software, den zwischengespeicherten Verbindungsstatus und Sicherheitskontrollen des Endgeräts. Gehen Sie nicht davon aus, dass die Startseite repräsentativ ist; testen Sie die konkrete fehlerhafte Route.

2. Prüfen, ob der Client Response-Header empfängt

Senden Sie von einem betroffenen oder nahegelegenen Client eine schreibgeschützte Anfrage an das autorisierte Ziel. Ersetzen Sie die Werte in eckigen Klammern durch den tatsächlichen Hostnamen und Pfad:

curl -v https://[your hostname]/[path]

Wenn die Verbindung ohne Response-Header geschlossen wird, spricht das für eine Diagnose als Empty Response. Wird ein HTTP-Status zurückgegeben, untersuchen Sie stattdessen diesen Status, eine Weiterleitung, das TLS-Verhalten oder die Browser-Darstellung. Vergleichen Sie nach Möglichkeit die ausführliche Ausgabe eines funktionierenden und eines fehlerhaften Clients.

3. Anfrage mit den Server-Logs abgleichen

Verwenden Sie die exakte Uhrzeit und den Pfad, um Folgendes zu prüfen:

1. Zugriffs- und Fehler-Logs von Nginx oder des zuständigen Webservers.
2. PHP-FPM-Logs, wenn die Route PHP aufruft.
3. Anwendungs-Logs auf fatale Fehler, nicht abgefangene Exceptions und fehlgeschlagene Abhängigkeiten.
4. Betriebssystem-Logs auf Out-of-Memory-Ereignisse, Prozessbeendigungen, erschöpfte File Descriptors und Dienstausfälle.

Ein Access-Log-Eintrag ohne abgeschlossene Upstream-Response, ein Upstream-Reset oder eine Meldung über die Beendigung eines Workers hilft dabei, die Ebene zu identifizieren, die die Verbindung geschlossen hat. Der Browserfehler allein kann die verantwortliche Komponente nicht bestimmen.

4. PHP-FPM- und Anwendungsgesundheit prüfen

Bestimmen Sie bei einer dynamischen Route, ob PHP-FPM verfügbare Worker hat und ob Worker wiederholt beendet werden, konfigurierte Limits erreichen oder vom Betriebssystem beendet werden. Prüfen Sie aktuelle Deployments, fatale Fehler, Speicherdruck, langsame Datenbankaufrufe und andere blockierte Abhängigkeiten.

Ändern Sie PHP-FPM-Limits, Anwendungscode oder den Dienststatus erst, nachdem Sie die relevanten Belege bestätigt und Kapazität sowie betriebliche Auswirkungen bewertet haben. Ein Neustart kann fehlerhafte Worker vorübergehend beseitigen, behebt aber keinen wiederkehrenden Absturz, keine Ressourcenerschöpfung und keinen Anwendungsfehler. Wenn ein Neustart autorisiert ist, sichern Sie Logs und den Prozessstatus, bevor Sie ihn durchführen.

5. Nginx-Verbindungs- und File-Descriptor-Kapazität prüfen

Prüfen Sie die effektive Nginx-Konfiguration und die Betriebssystem-Limits für den betroffenen Dienst. Untersuchen Sie worker_connections, das Verhalten der Worker-Prozesse, aktive Verbindungen, Open-File-Limits, verfügbaren Speicher und Fehlermeldungen, die auf ein erreichtes Ressourcenlimit hinweisen.

Erhöhen Sie worker_connections nicht einfach. Das File-Descriptor-Limit des Betriebssystems und der verfügbare Speicher müssen die Änderung unterstützen. Erfassen Sie aktuelle Werte und die Verkehrssituation, befolgen Sie das freigegebene Änderungsverfahren und überprüfen Sie das Ergebnis nach einem kontrollierten Reload oder Neustart, sofern dieser autorisiert ist.

6. Reverse-Proxy- oder Upstream-Fehler isolieren

Wenn ein CDN, Load Balancer, Ingress oder Nginx-Reverse-Proxy der Anwendung vorgeschaltet ist, vergleichen Sie:

• Die öffentliche Anfrage über den Proxy.
• Eine autorisierte Anfrage an den Upstream vom Proxy-Host oder von einem gleichwertigen internen Testpunkt.
• Proxy-Fehler-Logs und Upstream-Anwendungs-Logs für denselben Zeitstempel.

Prüfen Sie, ob der Proxy eine Verbindung wiederverwendet, die der Upstream bereits geschlossen hat, ob die Keepalive-Einstellungen kompatibel sind und ob Proxy- und Upstream-Timeouts für die Route geeignet sind. Ändern Sie jeweils nur eine zusammenhängende Einstellung, dokumentieren Sie die erwarteten Auswirkungen und wiederholen Sie denselben Test.

7. Netzwerk- und Sicherheitskontrollen prüfen

Wenn zum Fehlerzeitpunkt kein Eintrag im Webserver-Log existiert, untersuchen Sie Firewall, VPN, WAF, Load Balancer, Routing und den clientseitigen Sicherheitspfad. Vergleichen Sie ein funktionierendes Quellnetzwerk mit dem fehlerhaften und suchen Sie nach Policy-Entscheidungen, Verbindungs-Resets oder der Behandlung inaktiver Verbindungen, die zum Zeitstempel passen.

Wenn die Verbindung verschwindet, bevor sie den Webserver erreicht, wenden Sie sich an das Netzwerk- oder Hosting-Team, statt den Anwendungscode zu ändern.

8. Fehlerbehebung validieren und Beweise erhalten

Wiederholen Sie nach einer freigegebenen Änderung an Anwendung, Konfiguration oder Netzwerk dieselben Pfad- und Client-Tests. Bestätigen Sie, dass die Response nun Header und einen passenden HTTP-Status enthält – nicht nur, dass der Browser die ursprüngliche Meldung nicht mehr anzeigt. Prüfen Sie Proxy-, Webserver-, Upstream-, Anwendungs- und System-Logs und bewahren Sie die Konfigurationswerte vor und nach der Änderung zum Vergleich oder Rollback auf.

Vorbeugung und Überprüfung der Lösung

• Überwachen Sie Webserver-Fehler, Upstream-Resets, die Verfügbarkeit von PHP-FPM-Workern, Prozessbeendigungen, Speicherdruck, die Nutzung offener Dateien und Warnungen zu Verbindungslimits.
• Dokumentieren Sie Reverse-Proxy-, Upstream-Keepalive- und Timeout-Richtlinien und testen Sie sie nach Änderungen an der Infrastruktur.
• Fügen Sie Incident-Berichten eine Request-ID oder einen genauen Zeitstempel mit Zeitzone hinzu, damit Proxy-, Webserver- und Anwendungs-Logs abgeglichen werden können.
• Testen Sie Verbindungs- und File-Descriptor-Einstellungen unter Last, bevor Sie den Traffic erhöhen oder die Anzahl der Worker ändern.
• Führen Sie Anwendungsänderungen mit einem Rollback-Plan ein und achten Sie direkt danach auf fatale Fehler, Worker-Abstürze und Fehler bei Abhängigkeiten.
• Halten Sie ein autorisiertes Verfahren bereit, um sowohl den öffentlichen Endpunkt als auch den Upstream-Dienst getrennt zu testen.
• Führen Sie Dienstneustarts und Änderungen an Produktionslimits nur im Rahmen eines freigegebenen Änderungsprozesses durch.

Häufig gestellte Fragen