Documentation du Dr FRAPPE

Ce wiki regroupe les résultats de mes expériences en informatique accumulés au cours de mes recherches sur le net.

Dans la mesure du possible, j'ai cité mes sources ; il en manque certainement… :-)

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Révision précédente
logiciel:internet:nginx:start [2018/06/07 11:24]
logiciel:internet:nginx:start [2018/06/30 14:22] (Version actuelle)
admin
Ligne 1: Ligne 1:
 +{{tag>​Logiciel}}
  
 +<​title>​Nginx : le serveur Web hautes performances (LEMP)</​title>​
 +
 +====== - Introduction ======
 +
 +**nginx** ((<<​engine x>>)) est un serveur HTTP et reverse proxy, ainsi qu'un serveur proxy de mail.
 +
 +**nginx** fonctionne avec un processus maître qui gère plusieurs processus de travail ; ces derniers effectuent le traitement réel des demandes.
 +
 +Le nombre de processus de travail est défini dans le fichier de configuration ; il peut être ajusté automatiquement au nombre de cœurs disponibles du processeur.
 +
 +Voir le guide du débutant : [[logiciel:​internet:​nginx:​debutant|]]
 +
 +====== - Pré-requis ======
 +
 +===== - Ajouter le ppa =====
 +
 +  * Ajoutez le ppa stable :<​cli>​$ sudo add-apt-repository ppa:​nginx/​stable && sudo apt update</​cli>​
 +
 +===== - Définir l'​emplacement du répertoire de base du serveur =====
 +
 +<WRAP center round tip 60%>
 +Par défaut, la racine du site géré par **nginx** est située en **/​var/​www/​html** avec les droits **root**.
 +
 +Nous allons la déplacer vers un emplacement **/​[DISQUE]srv/​www/​html** avec des droits commodes.
 +
 +Pour cela, nous allons monter le nouvel emplacement dans **/​var/​www/​html** via le fichier **/​etc/​fstab**,​ sans toucher aux fichiers de configuration de **nginx**.
 +</​WRAP>​
 +
 +Créez le répertoire **/​[DISQUE]/​srv/​www/​html** :
 +<​cli>​$ sudo mkdir -p /​[DISQUE]/​srv/​www/​html</​cli>​
 +
 +éditez avec les droits d'​administration le fichier **/​etc/​fstab** pour ajouter à la fin les lignes suivantes :
 +<code - /​etc/​fstab>​
 +(...)
 +/​[DISQUE]/​srv /​srv none bind 0 0
 +/​srv/​www /​var/​www none bind 0 0
 +</​code>​
 +
 +<WRAP center round important 60%>
 +Si le disque **/​[DISQUE]** est en **ntfs**, il faut modifier sa ligne dans le fichier **fstab** en lui donnant le type **ntfs-3g** et en lui ajoutant l'​option **permissions**.
 +<code - >
 +UUID=XXXXXXXXXXXXXXXX /​media/​[DISQUE] ntfs-3g permissions,​defaults,​user,​utf8,​codepage=850 0 0
 +</​code>​
 +</​WRAP>​
 +
 +Appliquez le montage :
 +<cli>
 +$ sudo mount -a
 +</​cli>​
 +
 +Nous allons maintenant modifier les permissions pour que l'​utilisateur courant (**$USER**) puisse mettre à jour les pages Web sans avoir besoin d'​être root.
 +
 +Ajoutez l'​utilisateur courant au groupe **www-data** :
 +<cli>
 +$ sudo usermod -aG www-data $USER
 +</​cli>​
 +
 +Changez les permissions :
 +<​cli>​$ sudo chown -R www-data:​www-data /​[DISQUE]/​srv/​www</​cli>​
 +<​cli>​$ sudo chmod -R 2770 /​[DISQUE]/​srv/​www</​cli>​
 +
 +La racine du site est désormais **/​var/​www/​html -> /​[DISQUE]/​srv/​www/​html**,​ accessible au choix par **/​var/​www/​html** ou **/​[DISQUE]/​srv/​www/​html**.
 +
 +====== - Installation ======
 +
 +Installez le paquet **[[apt>​nginx]]** ou en ligne de commande :
 +<​cli>​$ sudo apt install nginx</​cli>​
 +
 +Vérification : en ouvrant [[http://​localhost]],​ il s'​affiche :
 +{{ :​logiciel:​internet:​nginx:​nginx_01.png |}}
 +
 +<WRAP center round info 60%>
 +Quand vous tapez l'​adresse [[http://​localhost]] ((ou [[http://​framboise.local]] pour un Rpi)), vous aboutissez dans le répertoire **/​[DISQUE]/​srv/​www/​html**.
 +
 +L'​utilisateur **$USER** (qui fait partie du groupe **www-data**) a lui aussi accès à ce répertoire.
 +
 +N'​oubliez pas de recharger la page du navigateur pour vider le cache, sinon c'est l'​ancienne page qui s'​affiche.
 +</​WRAP>​
 +====== - Configuration ======
 +
 +L'​installation a créé l'​arborescence :
 +
 +<a2s>
 +/etc/nginx/
 +|    * nginx.conf
 ++-- conf.d/
 ++-- modules-available/​
 ++-- modules-enabled/​
 ++-- sites-available/​
 +|    * default
 ++-- sites-enabled/​
 ++-- snippets/
 +</​a2s>​
 +
 +Le fichier de configuration ((qui pilote le fonctionnement de **nginx** et de ses modules)) de **nginx** est **/​etc/​nginx/​nginx.conf**.
 +
 +Pour en savoir plus sur le fichier de configuration,​ voir [[logiciel:​internet:​nginx:​nginx.conf|]]
 +
 +<WRAP center round important 60%>
 +Pour éviter des ennuis lors des mises à jour, nous ne toucherons pas au fichier /​etc/​nginx/​nginx.conf.
 +Au lieu de cela, nous utiliserons certains dossiers :
 +  * Pour la configuration,​ des fichiers spécifiques stockés dans le répertoire **/​etc/​nginx/​conf.d**.
 +  * Pour les hôtes virtuels, des fichiers spécifiques stockés dans le répertoire **/​etc/​nginx/​sites-available** ; ce répertoire contient un fichier modèle : **/​etc/​nginx/​sites-available/​default**
 +  * Le dossier **/​etc/​nginx/​sites-enabled** permet de lancer les hôtes virtuels en production
 +</​WRAP>​
 +
 +===== - Serveurs Virtuels =====
 +
 +Dans chacun des contextes de gestion du trafic, vous incluez un ou plusieurs blocs **server** pour définir les serveurs virtuels qui contrôlent le traitement des demandes.
 +
 +Les directives que vous pouvez inclure dans un contexte de serveur varient en fonction du type de flux.
 +
 +Pour le flux HTTP (contexte **http**), chaque directive **server** contrôle le traitement des demandes de ressources sur des domaines ou des adresses IP particuliers.
 +
 +Dans un contexte **server**, un ou plusieurs contextes **location** définissent comment traiter des groupes spécifiques d'URI.
 +
 +Pour le flux mail et TCP/UDP (contextes **mail** et **stream**) les directives **server** contrôlent chacune le traitement du trafic arrivant sur un port TCP ou un socket UNIX particulier.
 +
 +Vous pouvez partir du fichier exemple fourni :
 +<​cli>​moi@pc:​~$ sudo cp /​etc/​nginx/​sites-available/​default /​etc/​nginx/​sites-available/​localhost</​cli>​
 +
 +===== - Héritage =====
 +
 +En général, un contexte fils (contenu dans un autre contexte, son parent) hérite des paramètres des directives incluses au niveau parent.
 +
 +Certaines directives peuvent apparaître dans plusieurs contextes, ce qui vous permet de remplacer le paramètre hérité du parent en incluant la directive dans le contexte enfant.
 +
 +Par exemple, voir la directive **proxy_set_header**.
 +
 +===== - Configuration de Nginx en serveur Web =====
 +
 +À un niveau élevé, la configuration de Nginx en serveur Web consiste à définir les URL qu'il gère et comment il traite les requêtes HTTP pour les ressources de ces URL.
 +
 +À un niveau inférieur, la configuration définit un ensemble de serveurs virtuels qui contrôlent le traitement des demandes pour des domaines ou des adresses IP particuliers.
 +
 +Chaque serveur virtuel pour le flux HTTP définit des instances de configuration spéciales appelées **locations** qui contrôlent le traitement d'​ensembles spécifiques d'URI.
 +
 +Chaque **location** définit son propre scénario de réponse aux demandes qui lui correspondent.
 +
 +Nginx offre un contrôle total sur ce processus. Chaque **location** peut transmettre la demande par proxy ou renvoyer un fichier.
 +
 +En outre, l'URI peut être modifié, en redirigeant la demande vers un autre emplacement ou un serveur virtuel.
 +
 +En outre, un code d'​erreur spécifique peut être renvoyé et vous pouvez configurer une page spécifique pour chaque code d'​erreur.
 +
 +==== - Configuration de serveurs virtuels ====
 +
 +Le fichier de configuration de Nginx doit inclure au moins une directive **server** pour définir un serveur virtuel.
 +
 +Lorsque Nginx traite une requête, il sélectionne d'​abord le serveur virtuel qui servira la requête.
 +
 +Un serveur virtuel est défini par une directive **server** dans le contexte http, par exemple :
 +<code - >
 +http {
 +    server {
 +        # Server configuration
 +    }
 +}
 +</​code>​
 +
 +Il est possible d'​ajouter plusieurs directives **server** dans le contexte http pour définir plusieurs serveurs virtuels.
 +
 +Le bloc de configuration **server** inclut généralement une directive **listen** pour spécifier l'​adresse IP et le port (ou le socket et le chemin de domaine Unix) sur lesquels le serveur écoute les demandes.
 +
 +Les adresses IPv4 et IPv6 sont acceptées. Placez les adresses IPv6 entre crochets.
 +
 +Voici un exemple de configuration d'un serveur qui écoute l'​adresse IP 127.0.0.1 sur le port 8080 :
 +
 +<code - >
 +server {
 +    listen 127.0.0.1:​8080;​
 +    # The rest of server configuration
 +}
 +</​code>​
 +
 +Si le port est omis, c'est le port standard qui est utilisé.
 +
 +De même, si une adresse est omise, le serveur écoute toutes les adresses.
 +
 +Sans directive listen, le port standard est 80/tcp et le port par défaut est 8000/tcp, selon les privilèges du super-utilisateur.
 +
 +Si plusieurs serveurs correspondent à l'​adresse IP et au port de la requête, Nginx teste le champ d'​en-tête Host de la demande par rapport aux directives **server_name** dans les blocs server.
 +
 +Le paramètre **nom_serveur** peut être un nom complet (exact), un joker ou une expression régulière.
 +
 +Un joker est une chaîne de caractères qui inclut une astérisque début, à la fin ou les deux; l'​astérisque correspond à n'​importe quelle séquence de caractères.
 +
 +Nginx utilise la syntaxe Perl pour les expressions régulières;​ faites-les précéder du tilde (~). Cet exemple illustre un nom exact.
 +
 +<code - >
 +server {
 +    listen ​     80;
 +    server_name example.org www.example.org;​
 +    ...
 +}
 +</​code>​
 +Si plusieurs noms correspondent à l'​en-tête Host, Nginx sélectionne dans l'​ordre suivant la première correspondance trouvée :
 +  - Nom exact
 +  - Le joker le plus long commençant par un astérisque,​ tel que ***.example.org**
 +  - Le joker le plus long se terminant par un astérisque,​ tel que **mail.***
 +  - Première expression régulière correspondante (par ordre d'​apparition dans le fichier de configuration)
 +
 +Si le champ d'​en-tête Host ne correspond pas à un nom de serveur, Nginx achemine la demande au serveur par défaut pour le port sur lequel la requête est arrivée.
 +
 +Le serveur par défaut est le premier répertorié dans le fichier **nginx.conf**,​ sauf si vous incluez le paramètre **default_server** dans la directive **listen** pour désigner explicitement un serveur comme serveur par défaut.
 +
 +<code - >
 +server {
 +    listen ​     80 default_server;​
 +    ...
 +}
 +</​code>​
 +
 +==== - Configuration des emplacements ====
 +
 +Nginx peut envoyer le flux à différents proxys ou servir des fichiers différents en fonction des URI de la requête.
 +
 +Ces blocs sont définis à l'aide de la directive **location** placée dans une directive **server**.
 +
 +Par exemple, vous pouvez définir trois blocs **location** pour indiquer au serveur virtuel d'​envoyer des requêtes à un serveur proxy, d'​envoyer d'​autres demandes à un autre serveur proxy et de traiter le reste des demandes en envoyant des fichiers depuis le système de fichiers local.
 +
 +Nginx teste les demandes des URI en fonction des paramètres de toutes les directives **location** et appliquent les directives définies dans le bloc **location** correspondant.
 +
 +À l'​intérieur de chaque bloc d'​emplacement,​ il est généralement possible (à quelques exceptions près) de placer encore plus de directives **location** pour affiner le traitement de groupes de demandes spécifiques.
 +
 +<WRAP center round info 60%>
 +Dans ce guide, le mot **location** fait référence à un contexte **location**.
 +</​WRAP>​
 +
 +Il y a deux types de paramètres dans une directive **location** : les chaînes de préfixe (chemins) et les expressions régulières.
 +
 +Pour qu'une URI de requête corresponde à une chaîne de préfixe, elle doit commencer par la chaîne de préfixe.
 +
 +L'​exemple suivant de **location** avec un paramètre **pathname** correspond aux URI de requête qui commencent par **/​some/​path/​**,​ comme **/​some/​path/​document.html**. (mais ne correspond pas à /​my-site/​some/​path car /some/path n'est pas au début de cet URI.)
 +
 +<code - >
 +location /some/path/ {
 +    ...
 +}
 +</​code>​
 +
 +Une expression régulière est précédée du tilde (~) pour une correspondance sensible à la casse, ou du tilde-astérisque (~*) pour une correspondance insensible à la casse. L'​exemple suivant correspond aux URI qui incluent la chaîne .html ou .htm à n'​importe quelle position.
 +
 +<code - >
 +location ~ \.html? {
 +    ...
 +}
 +</​code>​
 +
 +Pour trouver l'​emplacement qui correspond le mieux à un URI, Nginx compare d'​abord l'URI aux emplacements avec une chaîne de préfixe.
 +
 +Il recherche ensuite les emplacements avec une expression régulière.
 +
 +Une priorité plus élevée est donnée aux expressions régulières,​ sauf si le modificateur ''​^~''​ est utilisé.
 +
 +Parmi les chaînes de préfixe, Nginx sélectionne la chaîne la plus spécifique (c'​est-à-dire la chaîne la plus longue et la plus complète).
 +
 +La logique exacte pour sélectionner un emplacement pour traiter une demande est donnée ci-dessous :
 +  - Tester l'URI avec toutes les chaînes de préfixe.
 +  - Le modificateur = (signe égal) définit une correspondance exacte de l'URI et d'une chaîne de préfixe. Si la correspondance exacte est trouvée, la recherche s'​arrête.
 +  - Si le modificateur ^~ (caret-tilde) précède la plus longue chaîne de préfixe correspondante,​ les expressions régulières ne sont pas vérifiées.
 +  - Stocke la chaîne de préfixe correspondante la plus longue.
 +  - Testez l'URI par rapport aux expressions régulières.
 +  - Arrêter à la première expression régulière correspondante et utiliser l'​emplacement correspondant.
 +  - Si aucune expression régulière ne correspond, utiliser l'​emplacement correspondant à la chaîne de préfixe stockée.
 +
 +Un cas d'​utilisation typique pour le modificateur = est les requêtes pour / (barre oblique).
 +
 +Si les demandes de / sont fréquentes,​ spécifier = / comme paramètre de la directive **location** accélère le traitement, car la recherche de correspondances s'​arrête après la première comparaison.
 +
 +<code - >
 +location = / {
 +    ...
 +}
 +</​code>​
 +
 +Un contexte **location** peut contenir des directives qui définissent la façon de résoudre une requête - soit servir un fichier statique, soit transmettre la requête à un serveur proxy.
 +
 +Dans l'​exemple suivant, les demandes qui correspondent au premier contexte **location** sont des fichiers servis depuis le répertoire /**data** et les requêtes correspondant au second sont transmises au serveur proxy qui héberge le contenu du domaine **www.example.com**.
 +
 +<code - >
 +server {
 +    location /images/ {
 +        root /data;
 +    }
 +
 +    location / {
 +        proxy_pass http://​www.example.com;​
 +    }
 +}
 +</​code>​
 +
 +La directive **root** spécifie le chemin du système de fichiers où rechercher les fichiers statiques à servir.
 +
 +L'URI de la demande associée à l'​emplacement est ajoutée au chemin pour obtenir le nom complet du fichier statique à servir.
 +
 +Dans l'​exemple ci-dessus, en réponse à une demande de **/​images/​example.png**,​ NGginx fournit le fichier **/​data/​images/​example.png**.
 +
 +La directive **proxy_pass** transmet la requête au serveur proxy accédé avec l'URL configurée.
 +
 +La réponse du serveur proxy est ensuite renvoyée au client.
 +
 +Dans l'​exemple ci-dessus, toutes les demandes avec des URI qui ne commencent pas par /images/ sont transmises au serveur proxy.
 +
 +==== - Utilisation de variables ====
 +
 +Vous pouvez utiliser des variables dans le fichier de configuration pour que les demandes de processus Nginx diffèrent selon les circonstances.
 +
 +Les variables sont des valeurs nommées qui sont calculées au moment de l'​exécution et sont utilisées comme paramètres pour les directives.
 +
 +Le nom d'une variable commence par le caractère $ (dollar).
 +
 +Les variables définissent des informations basées sur l'​état de Nginx, telles que les propriétés de la requête en cours de traitement.
 +
 +Un certain nombre de variables sont prédéfinies,​ telles que les variables HTTP principales,​ et vous pouvez définir des variables personnalisées à l'aide des directives **set**, **map** et **geo**.
 +
 +La plupart des variables sont calculées lors de l'​exécution et contiennent des informations relatives à une requête spécifique.
 +
 +Par exemple, **$remote_addr** contient l'​adresse IP du client et **$uri** contient la valeur actuelle de l'URI.
 +
 +==== - Renvoyer des codes d'​état spécifiques ====
 +
 +Certains URI de site Web exigent le retour immédiat d'une réponse avec une erreur spécifique ou un code de redirection,​ par exemple lorsqu'​une page a été déplacée temporairement ou définitivement.
 +
 +La méthode la plus simple consiste à utiliser la directive **return**. Par exemple :
 +
 +<code - >
 +location /wrong/url {
 +    return 404;
 +}
 +</​code>​
 +
 +Le premier paramètre de retour est un code de réponse.
 +
 +Le deuxième paramètre facultatif peut être l'URL d'une redirection (pour les codes 301, 302, 303 et 307) ou le texte à renvoyer dans le corps de la réponse. Par exemple :
 +
 +<code - >
 +location /​permanently/​moved/​url {
 +    return 301 http://​www.example.com/​moved/​here;​
 +}
 +</​code>​
 +
 +La directive **return** peut être incluse dans les contextes **location** et **server**.
 +
 +==== - Réécriture d'URI dans les demandes ====
 +
 +Une URI de requête peut être modifiée plusieurs fois lors du traitement de la demande grâce à l'​utilisation de la directive rewrite, qui a un paramètre facultatif et deux paramètres obligatoires.
 +
 +Le premier paramètre (obligatoire) est l'​expression régulière à laquelle l'URI de la requête doit correspondre.
 +
 +Le second paramètre est l'URI à substituer à l'URI correspondant.
 +
 +Le troisième paramètre facultatif est un indicateur qui peut interrompre le traitement d'​autres directives de réécriture ou envoyer une redirection (code 301 ou 302). Par exemple :
 +
 +<code - >
 +location /users/ {
 +    rewrite ^/​users/​(.*)$ /​show?​user=$1 break;
 +}
 +</​code>​
 +
 +Comme le montre cet exemple, le deuxième paramètre users capture en faisant correspondre les expressions régulières.
 +
 +Vous pouvez inclure plusieurs directives **rewrite** dans les contextes **server** et **location**.
 +
 +Nginx exécute les directives une par une dans l'​ordre où elles apparaissent.
 +
 +Les directives **rewrite** dans un contexte server sont exécutées une fois lorsque ce contexte est sélectionné.
 +
 +Une fois que Nginx a traité un ensemble d'​instructions de réécriture,​ il sélectionne un contexte d'​emplacement en fonction du nouvel URI.
 +
 +Si l'​emplacement sélectionné contient des directives de réécriture,​ elles sont exécutées à tour de rôle.
 +
 +Si l'URI correspond à l'un de ceux-ci, une recherche du nouvel emplacement démarre après le traitement de toutes les directives de réécriture définies.
 +
 +L'​exemple suivant montre les directives de réécriture en combinaison avec une directive **return**.
 +
 +<code - >
 +server {
 +    ...
 +    rewrite ^(/​download/​.*)/​media/​(.*)\..*$ $1/​mp3/​$2.mp3 last;
 +    rewrite ^(/​download/​.*)/​audio/​(.*)\..*$ $1/​mp3/​$2.ra ​ last;
 +    return ​ 403;
 +    ...
 +}
 +</​code>​
 +
 +Cet exemple de configuration distingue deux ensembles d'URI.
 +
 +Les URI tels que **/​download/​some/​media/​file** sont remplacés par **/​download/​some/​mp3/​file.mp3**.
 +
 +En raison du dernier indicateur, les directives suivantes (la seconde réécriture et la directive return) sont ignorées mais Nginx continue à traiter la demande, qui a maintenant un URI différent.
 +
 +De même, les URI tels que /​download/​some/​audio/​file sont remplacés par /​download/​some/​mp3/​file.ra.
 +
 +Si un URI ne correspond à aucune directive rewrite, Nginx renvoie le code d'​erreur 403 au client.
 +
 +Deux paramètres interrompent le traitement des directives de réécriture:​
 +  ? last
 +  : Arrête l'​exécution des directives de réécriture dans le contexte actuel server ou location, mais Nginx recherche les emplacements correspondant à l'URI réécrit et toutes les directives de réécriture dans le nouvel emplacement sont appliquées (ce qui signifie que l'URI peut être modifiée).
 +  ? break
 +  : Comme la directive break, arrête le traitement des directives de réécriture dans le contexte actuel et annule la recherche des emplacements correspondant au nouvel URI. Les directives de réécriture dans le nouvel emplacement ne sont pas exécutées.
 +
 +==== - Réécriture des réponses HTTP ====
 +
 +Parfois, vous devez réécrire ou modifier le contenu d'une réponse HTTP, en substituant une chaîne à une autre.
 +
 +Vous pouvez utiliser la directive **sub_filter** pour définir la réécriture à appliquer.
 +
 +La directive prend en charge les variables et les chaînes de substitutions,​ ce qui permet des changements plus complexes.
 +
 +Par exemple, vous pouvez modifier les liens absolus qui se réfèrent à un serveur autre que le proxy :
 +
 +<code - >
 +location / {
 +    sub_filter ​     /blog/ /​blog-staging/;​
 +    sub_filter_once off;
 +}
 +</​code>​
 +
 +Un autre exemple modifie la méthode de http:// en http_s_:// et remplace l'​adresse localhost par le nom d'​hôte dans le champ d'​en-tête de la requête.
 +
 +La directive **sub_filter_once** demande à Nginx d'​appliquer consécutivement les directives sub_filter dans un emplacement:​
 +
 +<code - >
 +location / {
 +    sub_filter ​    '​href="​http://​127.0.0.1:​8080/' ​   '​href="​https://​$host/';​
 +    sub_filter ​    '​img src="​http://​127.0.0.1:​8080/'​ 'img src="​https://​$host/';​
 +    sub_filter_once on;
 +}
 +</​code>​
 +
 +Notez que la partie de la réponse déjà modifiée avec le sub_filter ne sera pas remplacée à nouveau si une autre correspondance sub_filter se produit.
 +
 +==== - Gestion d'​erreurs ====
 +
 +Avec la directive **error_page**,​ vous pouvez configurer Nginx pour renvoyer une page personnalisée avec un code d'​erreur,​ remplacer un code d'​erreur différent dans la réponse ou rediriger le navigateur vers un autre URI.
 +
 +Dans l'​exemple suivant, la directive **error_page** spécifie la page (/404.html) à renvoyer avec le code d'​erreur 404.
 +
 +<code - >
 +error_page 404 /404.html;
 +</​code>​
 +
 +Notez que cette directive ne signifie pas que l'​erreur est renvoyée immédiatement (la directive return le fait), mais spécifie simplement comment traiter les erreurs lorsqu'​elles se produisent.
 +
 +Le code d'​erreur peut provenir d'un serveur proxy ou se produire lors du traitement par Nginx (par exemple, les résultats 404 lorsque Nginx ne trouve pas le fichier demandé par le client).
 +
 +Dans l'​exemple suivant, lorsque Nginx ne trouve pas une page, il remplace le code 401 par le code 301 et redirige le client vers http:/​example.com/​new/​path.html.
 +
 +Cette configuration est utile lorsque les clients tentent toujours d'​accéder à une page par son ancien URI.
 +
 +Le code 301 informe le navigateur que la page a été déplacée de façon permanente, et il doit remplacer automatiquement l'​ancienne adresse par la nouvelle au retour.
 +
 +<code - >
 +location /​old/​path.html {
 +    error_page 404 =301 http:/​example.com/​new/​path.html;​
 +}
 +</​code>​
 +
 +La configuration suivante est un exemple de transmission d'une requête au back end lorsqu'​un fichier est introuvable.
 +
 +Comme il n'y a pas de code d'​état spécifié après le signe égal dans la directive **error_page**,​ la réponse au client a le code d'​état renvoyé par le serveur proxy (pas nécessairement 404).
 +
 +<code - >
 +server {
 +    ...
 +    location /images/ {
 +        # Set the root directory to search for the file
 +        root /data/www;
 +
 +        # Disable logging of errors related to file existence
 +        open_file_cache_errors off;
 +
 +        # Make an internal redirect if the file is not found
 +        error_page 404 = /fetch$uri;
 +    }
 +
 +    location /fetch/ {
 +        proxy_pass http://​backend/;​
 +    }
 +}
 +</​code>​
 +
 +La directive **error_page** indique à Nginx d'​effectuer une redirection interne lorsqu'​un fichier n'est pas trouvé.
 +
 +La variable $uri dans le paramètre final de la directive **error_page** contient l'URI de la requête en cours, qui est transmise dans la redirection.
 +
 +Par exemple, si /​images/​some/​file n'est pas trouvé, il est remplacé par /​fetch/​images/​some/​fil et une nouvelle recherche d'​emplacement commence.
 +
 +Par conséquent,​ la requête se retrouve dans le deuxième contexte d'​emplacement et est envoyée par proxy à http: http://​backend/​.
 +
 +La directive **open_file_cache_errors** empêche d'​écrire un message d'​erreur si un fichier n'est pas trouvé.
 +
 +Ce n'est pas nécessaire ici car les fichiers manquants sont correctement gérés.
 +
 +===== - Servir le contenu statique =====
 +
 +Cette section décrit comment configurer Nginx pour servir du contenu statique, comment définir les chemins recherchés pour trouver les fichiers demandés, comment configurer les fichiers d'​index et comment régler Nginx ainsi que le noyau, pour une performance optimale.
 +
 +Une tâche importante du serveur Web consiste à diffuser des fichiers (comme des images ou des pages HTML statiques).
 +
 +Vous allez implémenter un exemple où, selon la demande, les fichiers seront servis à partir de différents répertoires locaux: **/​data/​www** (qui peut contenir des fichiers HTML) et **/​data/​images** (contenant des images).
 +
 +Cela nécessitera d'​éditer le fichier de configuration et de mettre en place un bloc server dans le bloc http avec deux blocs location.
 +
 +Commencez par créer le répertoire **/​data/​www/​html** et placez-y un fichier **index.html** avec un contenu textuel quelconque ; créez le répertoire **/​data/​images** et placez-y quelques images.
 +
 +Puis ouvrez le fichier de configuration. Le fichier de configuration par défaut inclut déjà plusieurs exemples du bloc server, généralement bien commentés.
 +
 +Pour l'​instant commentez tous ces blocs et démarrez un nouveau bloc server :
 +
 +<code - >
 +    http {
 +        server {
 +        }
 +    }
 +</​code>​
 +
 +Généralement,​ le fichier de configuration peut inclure plusieurs blocs server se distinguant par les ports sur lesquels ils écoutent et par les noms de serveurs.
 +
 +Une fois que nginx décide quel serveur traite une requête, il teste l'URI spécifié dans l'​en-tête de la requête par rapport aux paramètres des directives location définies dans le bloc server.
 +
 +Ajoutez au bloc server le bloc location suivant :
 +
 +<code - >
 +    location / {
 +        root /data/www;
 +    }
 +</​code>​
 +
 +Ce bloc location spécifie le préfixe '/'​ par rapport à l'URI de la requête.
 +
 +Pour les requêtes qui correspondent,​ l'URI sera ajouté au chemin spécifié dans la directive root, c'​est-à-dire **/​data/​www**,​ pour former le chemin vers le fichier demandé sur le système de fichiers local.
 +
 +Si plusieurs blocs location correspondent,​ nginx sélectionne celui avec le préfixe le plus long.
 +
 +Le bloc location ci-dessus fournit le préfixe le plus court, de longueur un, et donc, seulement si tous les autres blocs d'​emplacement ne parviennent pas à correspondre,​ c'est ce bloc qui sera utilisé.
 +
 +Ensuite, ajoutez le second bloc location :
 +<code - >
 +    location /images/ {
 +        root /data;
 +    }
 +</​code>​
 +
 +Il y aura correspondance pour les requêtes commençant par /images/ (l'​emplacement / correspond également à ces requêtes, mais a un préfixe plus court).
 +
 +La configuration résultante du bloc de serveur devrait ressembler à ceci :
 +<code - >
 +    server {
 +        location / {
 +            root /data/www;
 +        }
 +
 +        location /images/ {
 +            root /data;
 +        }
 +    }
 +</​code>​
 +
 +C'est déjà une configuration fonctionnelle d'un serveur qui écoute sur le port standard 80 et est accessible sur la machine locale à l'​adresse http://​localhost/​.
 +
 +En réponse à des requêtes dont les URI commencent par /images/, le serveur renverra des fichiers du répertoire /​data/​images.
 +
 +Par exemple, en réponse à la requête http://​localhost/​images/​example.png,​ nginx renverra le fichier **/​data/​images/​example.png**.
 +
 +Si ce fichier n'​existe pas, nginx renverra l'​erreur 404.
 +
 +Les demandes avec des URI ne commençant pas par /images/ seront mappées dans le répertoire /data/www.
 +
 +Par exemple, en réponse à la requête http://​localhost/​some/​example.html,​ nginx renverra le fichier /​data/​www/​some/​example.html.
 +
 +Pour appliquer la nouvelle configuration,​ démarrez nginx s'il n'est pas encore démarré ou envoyez le signal reload au processus maître de nginx, en exécutant :
 +<cli>
 +$ sudo nginx -s reload</​cli>​
 +
 +Si quelque chose ne fonctionne pas comme prévu, recherchez la cause dans les fichiers access.log et error.log du répertoire /​usr/​local/​nginx/​logs ou /​var/​log/​nginx.
 +
 +==== - Répertoire racine et fichiers d'​index ====
 +
 +La directive **root** spécifie le répertoire racine qui sera utilisé pour rechercher un fichier.
 +
 +Pour obtenir le chemin d'un fichier demandé, Nginx ajoute l'URI de la requête au chemin spécifié par la directive root.
 +
 +La directive peut être placée à n'​importe quel niveau dans les contextes **http**, **server** ou **location**.
 +
 +Dans l'​exemple ci-dessous, la directive **root** est définie pour un serveur virtuel.
 +
 +Elle s'​applique à tous les blocs location où la directive root n'est pas incluse pour redéfinir explicitement la racine :
 +
 +<code - >
 +server {
 +    root /www/data;
 +
 +    location / {
 +    }
 +
 +    location /images/ {
 +    }
 +
 +    location ~ \.(mp3|mp4) {
 +        root /www/media;
 +    }
 +}
 +</​code>​
 +
 +Ici, Nginx recherche un URI qui commence par **/​images/​** dans le répertoire **/​www/​data/​images/​** du système de fichiers.
 +
 +Mais si l'URI se termine par l'​extension **.mp3** ou **.mp4**, Nginx recherche plutôt le fichier dans le répertoire / www / media / car il est défini dans le bloc d'​emplacement correspondant.
 +
 +Si une requête se termine par une barre oblique, Nginx la traite comme une demande de répertoire et essaie de trouver un fichier d'​index dans le répertoire.
 +
 +La directive **index** définit le nom du fichier d'​index (par défaut index.html).
 +
 +Pour continuer avec l'​exemple,​ si l'URI de la requête est **/​images/​some/​path/​**,​ Nginx délivre le fichier /​www/​data/​images/​some/​path/​index.html s'il existe.
 +
 +Si ce n'est pas le cas, Nginx renvoie le code HTTP 404 (non trouvé) par défaut.
 +
 +Pour configurer Nginx pour qu'il renvoie une liste de répertoires générée automatiquement,​ incluez le paramètre **on** dans la directive **autoindex** :
 +
 +<code - >
 +location /images/ {
 +    autoindex on;
 +}
 +</​code>​
 +
 +Vous pouvez lister plus d'un nom de fichier dans la directive index. Nginx recherche les fichiers dans l'​ordre spécifié et renvoie le premier qu'il trouve.
 +
 +<code - >
 +location / {
 +    index index.$geo.html index.htm index.html;
 +}
 +</​code>​
 +
 +La variable $geo utilisée ici est une variable personnalisée définie via la directive geo. La valeur de la variable dépend de l'​adresse IP du client.
 +
 +Pour retourner le fichier d'​index,​ Nginx vérifie son existence puis effectue une redirection interne vers l'URI obtenue en ajoutant le nom du fichier d'​index à l'URI de base.
 +
 +La redirection interne entraîne une nouvelle recherche d'un emplacement et peut aboutir à un autre emplacement,​ comme dans l'​exemple suivant :
 +
 +<code - >
 +location / {
 +    root /data;
 +    index index.html index.php;
 +}
 +
 +location ~ \.php {
 +    fastcgi_pass localhost:​8000;​
 +    ...
 +}
 +</​code>​
 +
 +Ici, si l'URI d'une requête est /path/, et que /​data/​path/​index.html n'​existe pas mais que /​data/​path/​index.php existe, la redirection interne vers /​path/​index.php est mappée au deuxième emplacement.
 +
 +Par conséquent,​ la demande est envoyée par proxy.
 +
 +==== - Essayer plusieurs options ====
 +
 +La directive **try_files** vérifie si le fichier ou le répertoire spécifié existe ; Nginx effectue une redirection interne si c'est le cas, ou renvoie un code d'​état si ce n'est pas le cas.
 +
 +Par exemple, pour vérifier l'​existence d'un fichier correspondant à l'URI de la requête, utilisez la directive **try_files** et la variable $uri comme suit :
 +
 +<code - >
 +server {
 +    root /www/data;
 +
 +    location /images/ {
 +        try_files $uri /​images/​default.gif;​
 +    }
 +}
 +</​code>​
 +
 +Le fichier est spécifié sous forme de l'URI, qui est traité à l'aide des directives **root** ou **alias** définies dans le contexte de l'​emplacement actuel ou du serveur virtuel.
 +
 +Dans ce cas, si le fichier correspondant à l'URI d'​origine n'​existe pas, Nginx effectue une redirection interne vers l'URI spécifié par le dernier paramètre, en renvoyant /​www/​data/​images/​default.gif.
 +
 +Le dernier paramètre peut également être un code d'​état (directement précédé du signe égal) ou le nom d'un emplacement.
 +
 +Dans l'​exemple suivant, une erreur 404 est renvoyée si aucun des paramètres de la directive **try_files** ne se résout en un fichier ou un répertoire existant.
 +
 +<code - >
 +location / {
 +    try_files $uri $uri/ $uri.html =404;
 +}
 +</​code>​
 +
 +Dans l'​exemple suivant, si ni l'URI d'​origine ni l'URI avec la barre oblique finale ajoutée ne se résolvent en un fichier ou répertoire existant, la requête est redirigée vers l'​emplacement nommé qui le transmet à un serveur proxy.
 +
 +<code - >
 +location / {
 +    try_files $uri $uri/ @backend;
 +}
 +
 +location @backend {
 +    proxy_pass http://​backend.example.com;​
 +}
 +</​code>​
 +
 +Pour plus d'​informations,​ visionnez le webinaire à la demande [[https://​www.nginx.com/​resources/​webinars/​content-caching-nginx-plus/​|Content Caching]] pour apprendre à améliorer considérablement les performances d'un site Web et approfondir les capacités de mise en cache de Nginx.
 +
 +==== - Optimisation des performances pour le contenu diffusé ====
 +
 +La vitesse de chargement est un facteur crucial pour servir n'​importe quel contenu.
 +
 +Des optimisations mineures de votre configuration Nginx peut augmenter la productivité et aider à atteindre des performances optimales.
 +
 +=== - Activation de sendfile ===
 +
 +Par défaut, Nginx gère lui-même la transmission de fichiers et copie le fichier dans le tampon avant de l'​envoyer.
 +
 +L'​activation de la directive **sendfile** élimine l'​étape de copie des données dans le tampon et permet la copie directe des données d'un descripteur de fichier à un autre.
 +
 +Sinon, pour empêcher une connexion rapide d'​occuper entièrement le processus de travail, vous pouvez utiliser la directive **sendfile_max_chunk** pour limiter la quantité de données transférées dans un seul appel sendfile() (dans cet exemple, à 1 Mo) :
 +
 +<code - >
 +location /mp3 {
 +    sendfile ​          on;
 +    sendfile_max_chunk 1m;
 +    ...
 +}
 +</​code>​
 +
 +=== - Activation de tcp_nopush ===
 +
 +Utilisez la directive tcp_nopush avec la directive sendfile on.
 +
 +Ceci permet à NGINX d'​envoyer des en-têtes de réponse HTTP dans un paquet juste après que le bloc de données ait été obtenu par sendfile().
 +
 +<code - >
 +location /mp3 {
 +    sendfile ​  on;
 +    tcp_nopush on;
 +    ...
 +}
 +</​code>​
 +
 +=== - Activation de tcp_nodelay ===
 +
 +La directive tcp_nodelay permet de remplacer l'​algorithme de Nagle, conçu à l'​origine pour résoudre les problèmes liés aux petits paquets dans les réseaux lents.
 +
 +L'​algorithme consolide un nombre de petits paquets en un plus grand et envoie le paquet avec un retard de 200 ms.
 +
 +De nos jours, en servant de grands fichiers statiques, les données peuvent être envoyées immédiatement indépendamment de la taille du paquet.
 +
 +Le retard affecte également les applications en ligne (ssh, jeux en ligne, trading en ligne, etc.).
 +
 +Par défaut, la directive tcp_nodelay est définie sur **on**, ce qui signifie que l'​algorithme de Nagle est désactivé.
 +
 +N'​utilisez cette directive que pour les connexions keepalive :
 +
 +<code - >
 +location /mp3  {
 +    tcp_nodelay ​      on;
 +    keepalive_timeout 65;
 +    ...
 +}
 +</​code>​
 +
 +=== - Optimisation de la file d'​attente de backlog ===
 +
 +L'un des facteurs importants est la vitesse à laquelle Nginx peut gérer les connexions entrantes.
 +
 +La règle générale est que, lorsqu'​une connexion est établie, elle est placée dans la file d'​attente **listen** d'une socket d'​écoute.
 +
 +En charge normale, la file d'​attente est petite ou il n'y a aucune file d'​attente.
 +
 +Mais en cas de charge élevée, la file d'​attente peut augmenter considérablement,​ entraînant des performances inégales, des connexions interrompues et une latence accrue.
 +
 +__**Affichage de la file d'​attente d'​écoute**__
 +
 +Pour afficher la file d'​écoute actuelle, exécutez cette commande :
 +<cli>
 +$ netstat -Lan</​cli>​
 +
 +Dans la sortie suivante, dans la file d'​écoute sur le port 80, il y a 10 connexions non acceptées contre le maximum configuré de 128 connexions en file d'​attente. Cette situation est normale.
 +
 +<​cli>​Current listen queue sizes (qlen/​incqlen/​maxqlen)
 +Listen ​        Local Address ​        
 +0/​0/​128 ​       *.12345 ​           ​
 +10/​0/​128 ​       *.80       
 +0/​0/​128 ​       *.8080</​cli>​
 +
 +En revanche, dans la commande suivante, le nombre de connexions non acceptées (192) dépasse la limite de 128.
 +
 +C'est assez fréquent lorsqu'​un site Web a un trafic important.
 +
 +Pour obtenir des performances optimales, vous devez augmenter le nombre maximal de connexions pouvant être mises en file d'​attente pour acceptation par Nginx dans votre système d'​exploitation et dans la configuration Nginx.
 +
 +<​cli>​Current listen queue sizes (qlen/​incqlen/​maxqlen)
 +Listen ​        Local Address ​        
 +0/​0/​128 ​       *.12345 ​           ​
 +192/​0/​128 ​       *.80       
 +0/​0/​128 ​       *.8080
 +</​cli>​
 +
 +__**Réglage du système d'​exploitation**__
 +
 +Augmentez la valeur du paramètre net.core.somaxconn kernel de sa valeur par défaut (128) à une valeur suffisamment élevée pour une grande rafale de trafic.
 +
 +Dans cet exemple, il est passé à 4096.
 +
 +Pour Linux, exécutez la commande :
 +<cli>
 +$ sudo sysctl -w net.core.somaxconn=4096</​cli>​
 +
 +Utilisez un éditeur de texte pour ajouter la ligne suivante à **/​etc/​sysctl.conf** :
 +<code - >
 +   ​net.core.somaxconn = 4096
 +</​code>​
 +
 +__**Régler Nginx**__
 +
 +Si vous définissez le paramètre somaxconn kernel à une valeur supérieure à 512, remplacez le paramètre backlog par la directive listen Nginx pour qu'il corresponde :
 +
 +<code - >
 +server {
 +    listen 80 backlog 4096;
 +    # ...
 +}
 +</​code>​
 +
 +===== - Configuration d'un serveur proxy simple =====
 +
 +L'une des utilisations fréquentes de nginx consiste à le configurer en tant que serveur proxy, ce qui signifie qu'un serveur reçoit les demandes, les transmet aux serveurs proxy, récupère les réponses et les envoie aux clients.
 +
 +Nous allons configurer un serveur proxy de base, qui sert les demandes d'​images avec des fichiers du répertoire local et envoie toutes les autres demandes à un serveur proxy.
 +
 +Dans cet exemple, les deux serveurs seront définis sur une seule instance de nginx.
 +
 +Tout d'​abord,​ définissez le serveur proxy en ajoutant un bloc server supplémentaire au fichier de configuration de nginx :
 +
 +<code - >
 +    server {
 +        listen 8080;
 +        root /data/up1;
 +
 +        location / {
 +        }
 +    }
 +</​code>​
 +
 +Ce sera un serveur simple qui écoute sur le port 8080 (précédemment,​ la directive listen n'a pas été spécifiée puisque le port 80 standard était utilisé) et mappe toutes les demandes vers le répertoire /data/up1 sur le système de fichiers local.
 +
 +Créez ce répertoire et placez-y le fichier index.html.
 +
 +Notez que la directive root est placée dans le contexte server.
 +
 +Cette directive root est utilisée lorsque le bloc location sélectionné pour traiter une requête n'a pas sa propre directive racine.
 +
 +Ensuite, utilisez la configuration du serveur de la section précédente et modifiez-la pour en faire une configuration de serveur proxy.
 +
 +Dans le premier bloc location, mettez la directive proxy_pass en spécifiant le protocole, le nom et le port du serveur proxy dans le paramètre (dans notre cas, c'est http://​localhost:​8080) :
 +
 +<code - >
 +    server {
 +        location / {
 +            proxy_pass http://​localhost:​8080;​
 +        }
 +
 +        location /images/ {
 +            root /data;
 +        }
 +    }
 +</​code>​
 +
 +Nous allons modifier le second bloc location, qui pour l'​instant mappe les demandes avec le préfixe /images/ vers les fichiers du répertoire /​data/​images,​ pour qu'il corresponde aux demandes d'​images avec des extensions de fichier typiques. Le bloc location modifié ressemble à ceci :
 +
 +<code - >
 +    location ~ \.(gif|jpg|png)$ {
 +        root /​data/​images;​
 +    }
 +</​code>​
 +
 +Le paramètre est une expression régulière qui correspond à tous les URI se terminant par .gif, .jpg ou .png.
 +
 +Une expression régulière devrait être précédée par ~.
 +
 +Les requêtes correspondantes seront mappées dans le répertoire /​data/​images.
 +
 +Quand nginx choisit un bloc location pour servir une demande, il vérifie d'​abord des directives location qui spécifient des préfixes, en se souvenant de l'​endroit avec le plus long préfixe et vérifie ensuite les expressions régulières.
 +
 +S'il y a correspondance avec une expression régulière,​ nginx choisit cet endroit ; sinon, il choisit celui retenu plus tôt.
 +
 +La configuration résultante d'un serveur proxy ressemblera à ceci :
 +
 +<code - >
 +    server {
 +        location / {
 +            proxy_pass http://​localhost:​8080/;​
 +        }
 +
 +        location ~ \.(gif|jpg|png)$ {
 +            root /​data/​images;​
 +        }
 +    }
 +</​code>​
 +
 +Ce serveur filtre les requêtes se terminant par .gif, .jpg, ou .png et les mappe dans le répertoire /​data/​images (en ajoutant l'URI au paramètre de la directive root) et transmet toutes les autres requêtes au serveur mandaté configuré ci-dessus.
 +
 +Pour appliquer la nouvelle configuration,​ envoyez le signal de rechargement à nginx comme décrit plus haut.
 +
 +De nombreuses autres directives peuvent être utilisées pour configurer davantage une connexion proxy.
 +
 +===== - Configuration de la fonction proxy de FastCGI =====
 +
 +nginx peut être utilisé pour router des requêtes vers des serveurs FastCGI qui exécutent des applications construites avec différents frameworks et langages de programmation tels que PHP.
 +
 +La configuration nginx la plus basique pour travailler avec un serveur FastCGI comprend l'​utilisation de la directive fastcgi_pass au lieu de la directive proxy_pass, et des directives fastcgi_param pour définir les paramètres transmis à un serveur FastCGI.
 +
 +Supposons que le serveur FastCGI soit accessible sur localhost:​9000.
 +
 +En prenant pour base la configuration du proxy de la section précédente,​ remplacez la directive proxy_pass par la directive fastcgi_pass et remplacez le paramètre par localhost:​9000.
 +
 +En PHP, le paramètre SCRIPT_FILENAME est utilisé pour déterminer le nom du script et le paramètre QUERY_STRING est utilisé pour transmettre les paramètres de la requête.
 +
 +La configuration résultante serait:
 +
 +<code - >
 +    server {
 +        location / {
 +            fastcgi_pass ​ localhost:​9000;​
 +            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;​
 +            fastcgi_param QUERY_STRING ​   $query_string;​
 +        }
 +
 +        location ~ \.(gif|jpg|png)$ {
 +            root /​data/​images;​
 +        }
 +    }
 +</​code>​
 +
 +Cela va mettre en place un serveur qui acheminera toutes les demandes à l'​exception des demandes d'​images statiques au serveur proxy opérant sur localhost:​9000 via le protocole FastCGI.
 +
 +====== - Utilisation ======
 +
 +===== - Démarrage, arrêt et rechargement de la configuration =====
 +
 +Pour démarrer **nginx**, exécutez-le.
 +
 +Pour le contrôler une fois démarré, lancez l'​exécutable avec le paramètre -s :
 +<​cli>​$ sudo nginx -s signal</​cli>​
 +où //signal// peut être l'un des éléments suivants :
 +  ? stop
 +  : arrêt rapide
 +  ? quit
 +  : arrêt propre
 +  ? reload
 +  : recharger le fichier de configuration
 +  ? reopen
 +  : rouvrir les fichiers journaux
 +
 +Par exemple, pour arrêter les processus nginx en attendant que les processus de travail terminent de traiter les requêtes en cours, exécutez la commande :
 +<​cli>​$ sudo nginx -s quit</​cli>​
 +
 +Cette commande doit être exécutée sous le même utilisateur que celui qui a démarré nginx.
 +
 +Les modifications effectuées dans le fichier de configuration ne seront pas appliquées tant que la configuration ne sera pas rechargée ou redémarrée.
 +
 +Pour recharger la configuration,​ exécutez :
 +
 +<cli>
 +$ sudo nginx -s reload</​cli>​
 +
 +Quand il reçoit l'​ordre de recharger la configuration,​ le processus maître vérifie la syntaxe du nouveau fichier de configuration et essaie d'​appliquer cette configuration.
 +
 +En cas de succès, le processus maître démarre de nouveaux processus de travail et demande aux anciens processus de travail de se fermer.
 +
 +Sinon, le processus maître annule les modifications et continue de fonctionner avec l'​ancienne configuration.
 +
 +Les anciens processus de travail qui reçoivent une commande d'​arrêt cessent d'​accepter de nouvelles connexions et continuent à traiter les demandes en cours jusqu'​à ce que toutes ces demandes soient traitées.
 +
 +Après cela, l'​ancien processus de traitement s'​arrête.
 +
 +Un signal peut également être envoyé aux processus nginx à l'aide d'​outils Unix tels que l'​utilitaire kill.
 +
 +Dans ce cas, un signal est envoyé directement à un processus avec un ID de processus donné.
 +
 +L'ID de processus du processus maître nginx est écrit, par défaut, dans **nginx.pid** dans le répertoire **/​usr/​local/​nginx/​logs** ou **/​var/​run**.
 +
 +Par exemple, si l'ID de processus maître est 1628, pour envoyer le signal QUIT pour arrêter proprement nginx, exécutez :
 +
 +<cli>
 +$ sudo kill -s QUIT 1628</​cli>​
 +
 +Pour obtenir la liste de tous les processus nginx en cours d'​exécution,​ vous pouvez utiliser l'​utilitaire ps comme ceci :
 +<cli>
 +$ sudo ps -ax | grep nginx</​cli>​
 +
 +Pour plus d'​informations sur l'​envoi de signaux à nginx, voir la section (en) [[https://​nginx.org/​en/​docs/​control.html|Contrôle de nginx]].
 +
 +====== - Désinstallation ======
 +
 +====== - Voir aussi ======
 +
 +  * **(en)** [[https://​nginx.org/​en/​docs/​beginners_guide.html]]
 +  * **(en)** documentation :​[[https://​docs.nginx.com/​nginx/​admin-guide/​]]
 +  * **(fr)** [[https://​web.developpez.com/​tutoriels/​creer-serveur-web-nginx-php-mariadb/​|Créer un serveur Web Nginx + PHP7 + Maria DB (Mysql) + PhpMyAdmin sous Debian 9 Stretch]]
 +
 +----
 +//Basé sur << [[http://​|Article]] >> par Auteur.//

QR Code
QR Code logiciel:internet:nginx:start (generated for current page)