Filtrez les erreurs nginx par code de statut ou par indice du log et obtenez la cause probable ainsi que la modification de configuration qui la corrige. Couvre 502, 504, 403, 404 et 413.
Nginx renvoie 502 Bad Gateway quand il sert de proxy et que l'application derrière lui ne donne aucune réponse valide : l'application est arrêtée, écoute sur un autre port ou socket, ou a planté en pleine réponse. Démarrez l'application, faites pointer proxy_pass vers l'adresse sur laquelle elle écoute réellement, puis lisez le log d'erreurs de nginx pour connaître la raison exacte.
Ce que désigne chaque erreur nginx
Choisissez le code de statut que vous voyez, ou tapez un mot de votre log d'erreurs, et l'outil réduit la liste aux causes correspondantes. Chaque fiche indique la cause, la vérification qui la confirme et un extrait de configuration à adapter. Toutes les fiches sont affichées tant que vous ne filtrez pas.
En tant que visiteur, rien de ce que vous faites ne la provoque. Le proxy a contacté l'application derrière lui et n'a reçu aucune réponse valide. En tant que propriétaire du site, c'est votre application ou vos réglages de proxy, commencez donc par vérifier que le processus en amont tourne.
Un 502 signifie que l'amont a mal répondu ou a refusé la connexion. Un 504 signifie que nginx a attendu et que rien n'est arrivé à temps. Le premier désigne une application arrêtée ou qui plante, le second un traitement lent ou un timeout trop court.
Définissez client_max_body_size dans le bloc http, server ou location, par exemple client_max_body_size 20m;. La valeur par défaut est 1m. Une valeur de 0 désactive la vérification de taille, ce qui est rarement souhaitable sur un site public.
Quand l'URL se termine par une barre oblique, nginx cherche un fichier index comme index.html. S'il n'en existe aucun et qu'autoindex est désactivé, ce qui est le cas par défaut, il n'a rien à servir. Ajoutez le fichier index ou routez la requête avec try_files.
Son emplacement est défini par la directive error_log de votre configuration. Cherchez error_log dans votre nginx.conf et les fichiers inclus pour le trouver, car les paquets et les conteneurs le placent à des endroits différents.
Un point de départ pour une application sur le port 3000. Il transmet l'hôte et le schéma d'origine, définit des timeouts explicites et laisse de la place pour des en-têtes plus gros.
Testez avec nginx -t, puis rechargez. Adaptez le port et les limites à votre application.
L'application derrière nginx ne tourne pas, la connexion est donc refusée.
Faites un curl de l'adresse de proxy_pass depuis la machine nginx. Une connexion refusée le confirme.
Démarrez l'application avec un gestionnaire de processus qui la relance après un plantage.
proxy_pass pointe vers un port ou un socket sur lequel l'application n'écoute pas.
Comparez l'adresse de proxy_pass avec celle que l'application affiche au démarrage.
Faites-les correspondre exactement, y compris la partie hôte.
L'application envoie des en-têtes de réponse plus gros que le tampon dans lequel nginx les lit, par exemple avec beaucoup de cookies.
Cherchez une ligne de log indiquant que l'en-tête est trop gros.
Augmentez proxy_buffer_size pour cette location. Sa valeur par défaut est une page mémoire, 4k ou 8k.
L'application a mis plus longtemps que proxy_read_timeout entre deux lectures, 60 secondes par défaut.
Chronométrez la même requête directement sur l'application avec curl.
Accélérez l'endpoint ou déplacez le travail vers une tâche en arrière-plan. N'augmentez le timeout que pour cette location.
Nginx n'a même pas pu ouvrir une connexion dans le délai proxy_connect_timeout, 60 secondes par défaut.
Cherchez un pare-feu ou un hôte injoignable depuis le proxy.
Réparez le chemin réseau. La documentation de nginx précise que ce timeout ne peut généralement pas dépasser 75 secondes, l'augmenter n'aide donc pas.
Une URL se terminant par une barre oblique n'a pas de fichier index et autoindex est désactivé.
Listez le dossier vers lequel pointe root et cherchez index.html.
Ajoutez le fichier index, ou envoyez la requête à votre application avec try_files.
L'utilisateur du worker nginx ne peut pas lire le fichier ou entrer dans l'un des dossiers parents.
Cherchez dans le log d'erreurs une ligne permission denied qui cite le chemin.
Donnez à l'utilisateur du worker le droit de lecture sur les fichiers et le droit d'exécution sur chaque dossier parent.
Une règle allow ou deny a correspondu au visiteur. Les règles sont vérifiées dans l'ordre et la première correspondance l'emporte.
Lisez chaque ligne allow et deny qui s'applique à la location, de haut en bas.
Réordonnez les règles pour que l'allow précis vienne avant le deny all général.
root a été utilisé là où il fallait alias, donc nginx ajoute deux fois le préfixe de la location au chemin.
Reconstituez le chemin du fichier : root ajoute l'URI entière, alias remplace le préfixe trouvé.
Utilisez alias, avec une barre oblique finale des deux côtés, quand le nom du dossier diffère de l'URL.
Une route d'application monopage comme /dashboard n'a pas de fichier sur le disque.
La page d'accueil se charge mais un rafraîchissement sur n'importe quelle route interne échoue.
Rabattez-vous sur index.html avec try_files pour que le routeur de l'application gère le chemin.
Le corps de la requête dépasse client_max_body_size, 1m par défaut.
Les envois de moins d'un mégaoctet fonctionnent et les plus gros échouent.
Augmentez la limite uniquement pour la location d'envoi.
Code de statut
Tous les codes
Mots de votre log d'erreurs
par exemple : refused, timed out, denied
Vérification
Correction
{n} causes correspondantes
Aucune cause ne correspond. Effacez la recherche ou choisissez un autre code.
Commencer gratuitement · Sans carte bancaire