Page Bad Gateway personnalisée avec Nginx

Question

Est-il possible de servir une page d'erreur "Bad Gateway" personnalisée dans Nginx ?

Comme pour les pages 404 personnalisées.

Answer 1

Trois éléments doivent être en place pour que votre page d'erreur personnalisée s'affiche au lieu de l'erreur générique "Bad Gateway".

1. Vous devez créer un fichier html nommé par exemple "500.html" et le placer dans la racine. Dans le cas de Rails fonctionnant derrière Nginx, cela signifie le placer à l'adresse public/500.html.

2. Vous devez avoir une ligne dans votre fichier de configuration qui dirige au moins les erreurs 502 vers cette page 500.html comme ceci :

   error_page 502 /500.html;

3. Vous devez avoir un bloc d'emplacement pour /500.html dans votre fichier de configuration. Si votre racine est déjà définie, ce bloc peut être vide. Mais le bloc doit néanmoins exister.

   location /500.html{
   }

Answer 2

C'est similaire à la mise en place des pages 404 personnalisées. Voici ce que j'ai.

#site-wide error pages
error_page 404 /404.html;
error_page 500 502 503 504 /500.html;

Answer 3

En utilisant debian (9.3 stretch en fait) j'ai fait les étapes suivantes :

• créer /var/www/html/502.html avec le contenu de la page d'erreur 502

• modifier /etc/nginx/sites-enabled/mywebsite.conf

donc ça ressemble à ça :

server {
    listen 80; listen [::]:80;
    server_name www.mywebsite.com;

    error_page 502 /502.html;
    location /502.html {
        root /var/www/html;
    }
}

• puis redémarré nginx en utilisant service nginx restart

Answer 4

Bien que la réponse de @Larsenal soit techniquement correcte pour la configuration minimale, il y a des configurations communes qui font que cela ne fonctionnera pas. La réponse de @Jack Desert aborde ce point mais ne fournit pas une explication complète de la raison pour laquelle cela est nécessaire.

Supposons que nous ayons cette configuration (simplifiée par @Jack).

error_page 502 504 /my-error-page.html;

Ce que cela signifie, c'est que, dans le cas d'une erreur 502 ou 504 en interne, il faut réécrire l'URI original comme suit /my-error-page.html .

Ce que je pense que la plupart des gens ratent, c'est que ce alors passe par la même chaîne de traitement cela se passe comme si vous demandiez cette page directement. Cela signifie qu'elle passe par tous les mêmes contrôles du bloc de localisation.

Puisqu'une méthode courante pour faire un reverse proxy sur nginx est de configurer un location / { cet emplacement correspond /my-error-page.html et donc nginx essaie d'utiliser le proxy pour servir le fichier d'erreur . Puisqu'un cas d'utilisation courant est de servir un fichier statique dans le cas où le backend est en panne, servir cette page d'erreur à partir du backend échouera probablement aussi, faisant que nginx servira par défaut sa propre page d'erreur interne que nous avons essayé de remplacer en premier lieu.

Ainsi, une solution courante, celle que suggère @Jack Desert, est d'inclure une autre location qui correspondra à la /my-error-page.html URL avant le location / bloc. Notez que l'ordre des blocs d'emplacement dans la configuration de nginx n'a aucun effet ; il existe un ensemble de règles très spécifiques pour choisir la priorité des blocs d'emplacement en fonction de l'URL. Ce bloc d'emplacement doit avoir tout ce qui est nécessaire pour servir ce fichier comme tout autre fichier statique que nginx pourrait servir. Cela signifie qu'un root est nécessaire quelque part et que /my-error-page.html sera chargé par rapport à celui-ci ( root peut être défini à presque tous les niveaux de la configuration de nginx).

Answer 5

La question ne le dit pas, mais il est assez courant de rencontrer ce problème lorsque les API sont derrière un proxy nginx pass through, donc dans ce cas vous voulez que la réponse soit JSON et non HTML.

Mon approche préférée est d'utiliser simplement la fonctionnalité de redirection de l'interface utilisateur. error_page pour rediriger vers une page d'erreur sur le même site :

error_page 502 503 $scheme://$server_name/500.json;

C'est une ligne, vous pouvez réutiliser la même 500.json pour différents location et il n'y a pas besoin d'un mystérieux vide. location . Vous placez votre message d'erreur dans le 500.json à la racine de votre site. Je suppose que vous avez déjà un location / {...} qui sert des fichiers statiques.

Vous pouvez bien sûr utiliser cette même approche pour servir une page d'erreur HTML également.