SLBCloud
Intermédiaire8 min de lecture

502, 504, 413, 403 : décoder les erreurs nginx

Ce que chaque code veut vraiment dire, où regarder, et la correction — les cinq erreurs qui représentent la quasi-totalité des tickets.

Un code d'erreur nginx dit toujours deux choses : qui a échoué, et à quel moment. Les distinguer évite de chercher du mauvais côté pendant une heure.

502 Bad Gateway

nginx a voulu joindre votre application et n'a trouvé personne. Neuf fois sur dix, l'application est simplement arrêtée.

bash
sudo systemctl status mon-appli
sudo ss -tulpn | grep 3000            # quelque chose écoute-t-il ?
curl -I http://127.0.0.1:3000/        # répond-il en direct ?
sudo tail -5 /var/log/nginx/error.log
  • connect() failed (111: Connection refused) : rien n'écoute sur ce port.
  • connect() failed (113: No route to host) : la machine visée est injoignable — cas d'un proxy_pass vers un autre serveur.
  • no live upstreams : tous les serveurs du groupe sont marqués en échec.
  • Pour PHP : vérifiez que le chemin du socket dans fastcgi_pass existe vraiment (ls /run/php/).

504 Gateway Timeout

L'application répond, mais trop lentement : nginx a coupé au bout de 60 secondes. Le réflexe est d'augmenter le délai — c'est presque toujours le mauvais.

nginx
proxy_read_timeout 300s;   # pour un export ou un import légitime

Un 504 est un symptôme

Si une page met plus d'une minute, le problème est dans l'application : une requête SQL sans index, un appel à une API tierce qui traîne, une boucle. Allonger le délai transforme une erreur en page qui rame — les visiteurs partent avant, et le serveur garde des connexions ouvertes pour rien.

413 Request Entity Too Large

Un envoi de fichier a dépassé la limite. Elle est réglée à deux endroits, et les deux doivent être relevés.

nginx
client_max_body_size 64M;

Et côté PHP, dans php.ini

ini
upload_max_filesize = 64M
post_max_size = 64M

403 Forbidden

nginx a trouvé le fichier mais refuse de le servir. Deux causes : les droits, ou une règle deny.

bash
namei -l /var/www/monsite/index.html    # les droits de tout le chemin, dossier par dossier
sudo -u www-data cat /var/www/monsite/index.html

namei -l est l'outil qu'on oublie : un fichier lisible dans un dossier parent que www-data ne peut pas traverser reste inaccessible, et rien ne le laisse deviner.

404 sur un site qui a des routes

L'accueil marche, les autres pages non : il manque la règle qui renvoie tout à l'application au lieu de chercher un fichier.

nginx
location / {
    try_files $uri $uri/ /index.php?$query_string;   # PHP
    # ou, pour une application mono-page :
    # try_files $uri $uri/ /index.html;
}

Le tableau de correspondance

CodeQui a échouéPremier réflexe
502L'application, injoignablesystemctl status
504L'application, trop lenteLes journaux applicatifs, pas nginx
413nginx, avant l'applicationclient_max_body_size
403Les droits ou une règle denynamei -l
404Le routagetry_files
500L'application elle-mêmeSes propres journaux

Bloqué malgré tout ? Ouvrez un ticket : on répond en français, et on regarde votre machine si besoin.

Ouvrir un ticket