nginx: upstream prematurely closed connection while reading response header from upstream

So sieht die Meldung aus

2026/10/29 11:20:45 [error] 1234#1234: *4521 upstream prematurely closed connection while reading response header from upstream, client: 203.0.113.5, server: example.com, request: "POST /api/export HTTP/2.0", upstream: "http://127.0.0.1:8080/api/export"

Häufige Ursachen

• Der Backend-Prozess ist während der Anfrage abgestürzt oder beendet worden (Segfault, Out-of-Memory-Kill, ein Worker nach einem Anfragelimit neu gestartet).
• Das Backend wurde genau dann neu gestartet oder neu geladen, zum Beispiel durch ein Deployment oder einen Dienstmanager.
• Ein Protokollkonflikt: proxy_pass http:// auf einen Port, der HTTPS erwartet, oder fastcgi_pass auf einen reinen HTTP-Port.
• Das Backend schließt ruhende Keepalive-Verbindungen früher, als nginx sie wiederverwendet.
• Das Backend lehnt die Anfrage ab, zum Beispiel wegen eines zu großen Headers oder Bodys, und trennt die Verbindung.

Prüfen

1. Wie oft und bei welchen URLs
   grep 'prematurely closed' /var/log/nginx/error.log | tail -n 10Kopieren
2. Ist das Backend abgestürzt oder neu gestartet? (Beispiel PHP-FPM)
   journalctl -u 'php*-fpm' --since '1 hour ago' --no-pager | tail -n 30Kopieren
3. Hat der Kernel einen Prozess beendet?
   sudo dmesg -T | grep -iE 'out of memory|killed process|segfault' | tail -n 10Kopieren
4. Antwortet das Backend direkt? (Port anpassen)
   curl -sv -o /dev/null http://127.0.0.1:8080/Kopieren

Lösung

• Herausfinden, warum das Backend stirbt: dessen eigenes Log und das Kernel-Log lesen, zuerst Abstürze oder Speichermangel beheben.
• Das Schema prüfen: proxy_pass https://... für ein TLS-Backend, fastcgi_pass nur für FastCGI-Sockets oder -Ports.
• Wird Keepalive zum Backend genutzt, den Idle-Timeout des Backends höher als nginx' keepalive_timeout im upstream-Block setzen.
• Das Backend nicht unter Last neu starten: bei Deployments einen sanften Reload (systemctl reload ...) nutzen.
• Testen und anwenden: nginx -t && systemctl reload nginx.

Häufige Fragen

Wie unterscheidet sich das von 111 Connection refused?

Bei 111 lauscht nichts auf dem Port. Hier wurde die Verbindung angenommen und dann ohne Antwort geschlossen, der Prozess läuft also, scheitert aber oder trennt.

Warum passiert es nur bei manchen Anfragen?

Meist lösen genau diese Anfragen den Absturz aus oder überschreiten ein Limit, zum Beispiel ein großer Export oder Upload. Vergleiche die fehlschlagenden URLs im Log.