Die meiste Zeit, die ein Fehler kostet, geht beim Lesen des falschen Logs verloren. Jedes beantwortet eine andere Frage, und zuerst die richtige Datei zu wählen macht den Rest meist schnell.

  • /var/log/nginx/error.log — der Webserver konnte seine Arbeit nicht tun: Upstream verweigert, Zugriff verweigert, Datei nicht gefunden.
  • /var/log/nginx/access.log — was angefragt und was geliefert wurde. Hier finden Sie das WANN.
  • /var/log/php8.3-fpm.log — sterbende Worker, Pool-Probleme.
  • das Anwendungslog — Ihr eigener Code. Der Stacktrace wohnt hier und sonst nirgends.

Schauen Sie zu, während Sie den Fehler auslösen

tail -f /var/log/nginx/error.log

Lassen Sie das laufen, rufen Sie die kaputte Seite auf und lesen Sie, was erscheint. Das ist der wirksamste Debugging-Schritt überhaupt, und er dauert zehn Sekunden.

Finden Sie die Form des Problems

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head
grep ' 500 ' /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

Der erste zeigt die Verteilung der Statuscodes. Der zweite nennt die fehlschlagenden URLs nach Häufigkeit — und eine einzelne URL macht meist den Großteil aus.

Nach Zeit eingrenzen

sed -n '/04\/Sep\/2026:14:0/,/04\/Sep\/2026:14:2/p' access.log | grep ' 50'

Auf das erste Auftreten kommt es an

Lesen Sie den ERSTEN Fehler eines Ausbruchs, nicht den letzten. Die späteren sind meist Folgen — eine sich stauende Warteschlange, ein erschöpfter Verbindungspool — und eine Folge zu beheben ändert nichts.
Ist das Log leer, obwohl offensichtlich etwas gescheitert ist, hat die Anfrage diese Schicht nie erreicht. Gehen Sie eine Schicht nach außen: kein PHP-Fehler heißt, Nginx hat sie abgewiesen; kein Nginx-Eintrag heißt, sie ist nie angekommen.