L'essentiel du temps perdu sur une panne passe à lire le mauvais journal. Chacun répond à une question différente, et choisir d'abord le bon fichier rend en général la suite rapide.

  • /var/log/nginx/error.log — le serveur web n'a pas pu faire son travail : refus en amont, permission refusée, fichier introuvable.
  • /var/log/nginx/access.log — ce qui a été demandé et ce qui a été renvoyé. C'est là qu'on trouve le QUAND.
  • /var/log/php8.3-fpm.log — des processus qui meurent, des problèmes de pool.
  • le journal de l'application — votre propre code. La trace d'exécution habite là et nulle part ailleurs.

Regardez-le pendant que vous reproduisez

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

Laissez cela tourner, chargez la page cassée et lisez ce qui apparaît. C'est l'étape de débogage la plus efficace qui soit, et elle prend dix secondes.

Trouvez la forme du problème

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

La première montre la répartition des codes de statut. La seconde nomme les adresses qui échouent, classées par fréquence — et une seule adresse en représente généralement la majorité.

Resserrez par le temps

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

C'est la première occurrence qui compte

Lisez la PREMIÈRE erreur d'une rafale, pas la dernière. Les suivantes sont d'ordinaire des conséquences — une file qui s'accumule, un pool de connexions qui s'épuise — et corriger une conséquence ne change rien.
Si le journal est vide alors que quelque chose a manifestement échoué, la requête n'a jamais atteint cette couche. Remontez d'une couche : pas d'erreur PHP signifie que Nginx l'a refusée ; pas d'entrée Nginx signifie qu'elle n'est jamais arrivée.