Comment configurer Nginx pour utiliser des pages d’erreur personnalisées sur Ubuntu 14.04

introduction

Nginx est un serveur Web hautes performances capable de fournir du contenu avec souplesse et puissance. Lors de la conception de vos pages Web, il est souvent utile de personnaliser chaque élément de contenu visible par vos utilisateurs. Cela inclut les pages d’erreur pour les demandes de contenu non disponible. Dans ce guide, nous montrerons comment configurer Nginx pour qu’il utilise des pages d’erreur personnalisées sous Ubuntu 14.04.

Conditions préalables

Pour commencer à utiliser ce guide, vous aurez besoin d’un utilisateur non root avec les privilèges + sudo +. Vous pouvez configurer un utilisateur de ce type en suivant notre https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04 (guide de configuration initiale pour Ubuntu 14.04). .

Nginx devra également être installé sur votre système. Apprenez à configurer cela en suivant this guide.

Lorsque vous avez terminé les étapes ci-dessus, continuez avec ce guide.

Création de vos pages d’erreur personnalisées

Nous allons créer quelques pages d’erreur personnalisées à des fins de démonstration, mais vos pages personnalisées seront évidemment différentes.

Nous allons placer nos pages d’erreurs personnalisées dans le répertoire + / usr / share / nginx / html + où Nginx d’Ubuntu définit la racine de son document par défaut. Nous allons créer une page pour les erreurs 404 appelée + custom_404.html + et une autre pour les erreurs générales de niveau 500, appelée + custom_50x.html +. Vous pouvez utiliser les lignes suivantes si vous ne faites que tester. Sinon, placez votre propre contenu à ces emplacements:

echo "<h1 style='color:red'>Error 404: Not found :-(</h1>" | sudo tee /usr/share/nginx/html/custom_404.html
echo "<p>I have no idea where that file is, sorry.  Are you sure you typed in the correct URL?</p>" | sudo tee -a /usr/share/nginx/html/custom_404.html
echo "<h1>Oops! Something went wrong...</h1>" | sudo tee /usr/share/nginx/html/custom_50x.html
echo "<p>We seem to be having some technical difficulties. Hang tight.</p>" | sudo tee -a /usr/share/nginx/html/custom_50x.html

Nous avons maintenant deux pages d’erreur personnalisées que nous pouvons utiliser lorsque les demandes des clients génèrent des erreurs différentes.

Configuration de Nginx pour utiliser vos pages d’erreur

Maintenant, nous devons simplement dire à Nginx que ces pages doivent être utilisées chaque fois que les conditions d’erreur correctes se produisent. Ouvrez le fichier de blocage du serveur dans le répertoire + / etc / nginx / sites-enabled + que vous souhaitez configurer. Nous allons utiliser le fichier de blocage de serveur par défaut appelé + default +, mais vous devez ajuster vos propres blocs de serveur si vous utilisez un fichier autre que celui par défaut:

sudo nano /etc/nginx/sites-enabled/default

Nous pouvons maintenant indiquer à Nginx nos pages d’erreur personnalisées.

Erreurs Directes 404 à la page personnalisée 404

Utilisez la directive + error_page + afin que, lorsqu’une erreur 404 se produit (lorsqu’un fichier demandé n’est pas trouvé), la page personnalisée que vous avez créée soit servie. Nous allons créer un bloc d’emplacement pour le fichier, dans lequel nous pourrons nous assurer que la racine correspond à l’emplacement de notre système de fichiers et que le fichier n’est accessible que par le biais de redirections internes Nginx (non demandables directement par les clients):

/ etc / nginx / sites-enabled / default

server {
       listen 80 default_server;
       listen [::]:80 default_server ipv6only=on;

       . . .






}

Habituellement, il ne serait pas nécessaire de définir le + root + dans le nouveau bloc d’emplacement car il correspond à la racine du bloc serveur. Cependant, nous sommes explicites ici pour que nos pages d’erreur soient servies même si nous déplaçons notre contenu Web normal et la racine du document associée vers un emplacement différent.

Dirigez les erreurs de niveau 500 vers la page Custom 50x

Nous pouvons ensuite ajouter les directives pour nous assurer que, lorsque Nginx rencontrera des erreurs de niveau 500 (problèmes liés au serveur), il servira l’autre page personnalisée que nous avons créée. Cela suivra exactement la même formule que nous avons utilisée dans la dernière section. Cette fois, nous définissons plusieurs erreurs de niveau 500 à utiliser toutes les pages + custom_50x.html +:

/ etc / nginx / sites-enabled / default

server {
       listen 80 default_server;
       listen [::]:80 default_server ipv6only=on;

       . . .

       error_page 404 /custom_404.html;
       location = /custom_404.html {
               root /usr/share/nginx/html;
               internal;
       }










}

En bas, nous avons également ajouté une passe FastCGI factice afin de pouvoir tester notre page d’erreur de niveau 500. Cela ne fonctionnera pas correctement car le backend n’existe pas. Demander une page ici nous permettra de vérifier que des erreurs de niveau 500 servent notre page personnalisée.

Enregistrez et fermez le fichier lorsque vous avez terminé.

Redémarrage de Nginx et test de vos pages

Testez la syntaxe de votre fichier de configuration en tapant:

sudo nginx -t

Si des erreurs ont été signalées, corrigez-les avant de continuer. Si aucune erreur de syntaxe n’est renvoyée, redémarrez Nginx en tapant:

sudo service nginx restart

Maintenant, lorsque vous accédez au domaine ou à l’adresse IP de votre serveur et demandez un fichier inexistant, vous devriez voir la page 404 que nous avons configurée:

http:///thiswillerror

image: https: //assets.digitalocean.com/articles/nginx_custom_error_1404/custom_404.png [nginx custom 404]

Lorsque vous vous rendrez à l’emplacement que nous avons configuré pour le laissez-passer FastCGI, nous recevons une erreur 502 passerelle incorrecte avec notre page personnalisée à 500 niveaux:

http:///testing

image: https: //assets.digitalocean.com/articles/nginx_custom_error_1404/custom_50x.png [nginx custom 50x]

Vous pouvez maintenant revenir en arrière et supprimer le faux emplacement de passe FastCGI de votre configuration Nginx.

Conclusion

Vous devriez maintenant servir des pages d’erreur personnalisées pour votre site. C’est un moyen simple de personnaliser l’expérience de vos utilisateurs, même en cas de problème. Une suggestion pour ces pages est d’inclure des liens vers des endroits où ils peuvent aller pour obtenir de l’aide ou plus d’informations. Dans ce cas, assurez-vous que les destinations de lien sont accessibles même lorsque les erreurs associées se produisent.

TOC